Большинству пользователей рекомендуется использовать либо -stable либо release. Как уже было сказано, многие пользователи используют -current, и, что очень важно, некоторые делают это для обнаружения ошибок и тестирования новых возможностей и функциональности.
Последний доступный snapshot это все, что обычно необходимо для запуска -current.
Если вы хотите собрать все из исходников, используйте только последний доступный
snapshot.
Этого можно добиться при помощи опции -s
утилиты
sysupgrade(8).
Проверьте страницу о
последних -current и использования snapshots,
чтобы ознакомиться с последними изменениями конфигурации или дополнительными
шагами, необходимыми для сборки из исходников.
Не исключено, что вы обнаружите ошибки в snapshots. Собственно это и является причиной, почему они собираются и доступны всем для скачивания. Если вы нашли баг, не стесняйтесь сообщить о нем, если этого еще не сделал кто-то другой.
Проверьте и убедитесь, что у вас установлена самая последняя доступная версия системы. Это должна быть либо OpenBSD x.y, если вы хотите обновиться до OpenBSD x.y-stable, либо последний snapshot, если вы хотите обновиться до -current.
cvs checkout
. После этого, чтобы обновить уже
существующие или дозагрузить новые файлы из того же репозитория, надо
будет сделать cvs update
.
Вы так же можете настроить и поддерживать свой локальный CVS репозиторий
при помощи программы reposync
, доступной в виде
пакета.
О настройке зеркала репозитория рассказывается на странице,
посвященной анонимному CVS.
/usr/src
(где обычно находятся загруженные
исходники) открыт на запись для участников группы wsrc
по
умолчанию, так что добавьте пользователей, которым нужно пользоваться
cvs(1), в эту группу.
# user mod -G wsrc exampleuserИзменения вструпят в силу после следующего входа в систему этого пользователя.
Если вы хотите загрузить исходники xenocara или портов от имени этого пользователя, потребуется создать каталог и установить права доступа вручную.
# cd /usr # mkdir -p xenocara ports # chgrp wsrc xenocara ports # chmod 775 xenocara ports
src
дерева исходников, укажите branch,
который вам нужен, при помощи параметра -r
:
$ cd /usr $ cvs -qd anoncvs@anoncvs.example.org:/cvs checkout -rOPENBSD_7_6 -P srcПосле того как вы загрузили исходники, вы можете обновить/синхронизировать дерево в любое время при помощи следующих команд:
$ cd /usr/src $ cvs -q up -Pd -rOPENBSD_7_6Замените
src
на xenocara
или ports
в зависимости от того, что именно вы планируете сделать.
Так как все части OpenBSD тесно взаимосвязаны между собой, все деревья
с исходниками, с которыми вы работаете, должны загружаться и обновляться синхронно.
src
дерева исходников, воспользуйтесь
следующими командами:
$ cd /usr $ cvs -qd anoncvs@anoncvs.example.org:/cvs checkout -P srcОбновить их можно можно вот так:
$ cd /usr/src $ cvs -q up -Pd -AЗамените
src
на необходимый вами модуль, такой как xenocara
или ports
.
Если вы собираете -current, просмотрите изменения, а также специальные инструкции по сборке, перечисленные на этой странице.
Следуйте детальным инструкциям, описанным в шагах 2 и 3 руководства по release(8).
Инструкции по сборке релиза находятся в
release(8).
Этот процесс использует бинарники в /usr/obj
, процесс создания
которых описывался выше.
Замечание: если вы захотите использовать эти файлы для установки или обновлении
через/используя HTTP(S), создайте файл index.txt
, который будет
содержать список всех файлов, вошедьших в новый релиз.
# ls -nT > index.txtЕсли вы хотите подписать созданные файлы, man-страница по signify(1) расскажет как это сделать.
noperm
-раздела.
Это позволит инфраструктуре сборки использовать непривилегированного
пользователя build
для большей части процесса.
Создайте ФС на /dest
с установленной noperm
mount(8) опцией.
Соответствующая fstab(5)
строка должна быть похожа на эту:
c73d2198f83ef845.m /dest ffs rw,nosuid,noperm 1 2Владельцем (owner) этой ФС должен быть пользователь
build
,
который имеет там права 700
:
# chown build /dest # chmod 700 /destСоздайте каталог
DESTDIR
для base и xenocara:
# mkdir /dest/{,x}baseВаша
RELEASEDIR
не обязательно должна быть на noperm
ФС. Удоставерьтесь, что она пренадлежит пользователю build
и имеет
права u=rwx
.
/etc/fstab
:
swap /dest mfs rw,nosuid,noperm,-P/var/dest,-s1.5G,noauto 0 0Создайте прототип каталога
DESTDIR
:
# mkdir -p /var/dest/{,x}base # chown -R build /var/dest # chmod -R 700 /var/destТеперь вы можете подмонтировать
/dest
до того как приступили
к сборке релиза:
# mount /dest
Чтобы упростить жизни пользователям OpenBSD, была разработана система, получившая название Xenocara. Эта система "конвертирует" X обратно в одно общее большее дерево исходных кодов. В качестве дополнительного бонуса, этот процесс сборки стал похож на аналогичные процессы, используемые остальными компонентами OpenBSD.
Официальные инструкции по сборке X находятся в файле
xenocara/README
, а так же описаны в пятом шаге
release(8).
Чаще всего можно столкнуться со следующими:
make obj
перед make build
make build
до make obj
приведет к тому, что
целая куча объектных файлов будет разбросана в /usr/src
каталоге.
Это плохо. Чтобы не загужать исходники (src tree) снова, удалите obj-файлы:
$ cd /usr/src $ find . -type l -name obj -delete $ make cleandir $ rm -rf /usr/obj/* $ make obj
Имеет смысл починить или заменить компоненты, которые приводят к этой проблеме, так как они скорее всего будут проявлять себя и в будущем.
Для получения дополнительной информации смотрите Sig11 FAQ.
wobj
wobj
.
Это даст вам права на запись в каталог /usr/obj
.
Для большинства программ или архивов с исходниками (library source
directories), вы можете создать ./tags
файлы вот так:
$ make tagsВо время сборки и установки
libc
, создается файл
/var/db/libc.tags
.
По умолчанию, tags ядра для каждой архитектуры находится в
/sys/arch/$(machine)/
.
Эти файлы могут быть созданы при помощи make tags
, запущенной
в /sys/kern
.
Вы можете выполнить make links
от root, чтобы создать symlink
на tags
файл вашего ядра в каждом каталоге и в
/var/db/
.
SKIPDIR
в
mk.conf(5).
Когда разработчики начинают поддерживать новую платформу, одним из первых важнейших тестов является так называемый "native building", т.е. процесс сборки системы на той же платформе, для которой она собирается. Сборка системы из исходников значительно нагружает и саму ОС, и машину, что само по себе является хорошим тестом работоспособности. По этой причине в OpenBSD используется метод сборки всех компонентов на платформе, для которой она собирается и на которой планируется использоваться.
Для загрузки в User Kernel Config, или UKC, используйте опцию
-c
при загрузке.
Using drive 0, partition 3. Loading...... probing: pc0 com0 com1 mem[638K 1918M a20=on] disk: hd0+ hd1+ >> OpenBSD/amd64 BOOT 3.33 boot> boot hd0a:/bsd -cПосле этого появится приглашение UKC. Используйте комадну
help
чтобы получить список доступных
команд.
Использование boot_config(8) дает лишь временное одноразовое изменение, т.е. процедуру придется повторять каждый раз после перезагрузки. В следующем разделе объясняется, как сделать изменения постоянными.
-e
позволит войти в UKC в запущенной системе.
Все внесенные изменения вступят в силу после перезагрузки.
Параметр -u
проверяет, были ли внесены изменения в ядро во
время загрузки, т.е. использовали ли вы параметр boot -c
для входа в UKC во время загрузки системы.
Чтобы избежать риска перезаписи рабочего ядра сломанным, предусмотрена
возможность использования параметра -o
для сохранения
нового измененного ядра в новый файл для тестирования:
# config -e -o /bsd.new /bsdТаким образмо можно сохранить новое ядро в
/bsd.new
файл.
После того, как вы загрузили это новое ядро и убедились, что все
работает, изменения можно сделать постоянными, поместив их в
bsd.re-config(5).
Это избавит от необходимости выбирать ядро при загрузке и гарантирует,
что hibernation и линковка ядра (kernel relinking) продолжат работать.
Примеры конфигурации ядра можно найти в man-странице для config(8).
GENERIC
и GENERIC.MP
ядра поддерживаются командой
разработчиков.
Конфигурация GENERIC
ядра зависит от комбинации параметров в
/sys/arch/$(machine)/conf/GENERIC
и /sys/conf/GENERIC
.
Сообщение о проблеме в собственно собраном ядре практически всегда приведет к
тому, что вам предложат попытаться воспроизвести проблему с GENERIC
ядром.
Ознакомьтесь с документацией для config(8) и options(4). Следующие шаги являются частью процесса сборки собственного ядра:
$ cd /sys/arch/$(machine)/conf $ cp GENERIC CUSTOM $ vi CUSTOM # make your changes $ config CUSTOM $ cd ../compile/CUSTOM $ make
cvs diff -uNp
.
$ git config diff.noprefix trueпосле чего создать diff можно будет вот так:
$ git diff --relative .