OpenBSD Порты: Отличие от других BSD проектов

OpenBSD Порты - Отличие от других BSD проектов [Порты - На главную]

Дополнительная помощь
Общие вопросы по поводу инфраструктуры
Правильное использование make
Распаковка (извлечение) исходников
Инфраструктура WRKDIR
Fake установка порта
Packaging инструменты
Flavors

Дополнительная помощь

Инфраструктура портирования включает в себя несколько скриптов, которые находятся в infrastructure/bin. Они предназначены для упрощения процесса создания новых портов:

check-lib-depends: Запускается при помощи make lib-depends-check с целью проверки shared libraries зависимостей.
update-patches: Запускается при помощи make update-patches, который всегда должен использоваться для обновления/регенерации патчей.
update-plist: Запускается при помощи make update-plist. Этот скрипт позаботится о аккуратности packing-lists. OpenBSD packing-lists значительно отличаются от своих сородичей из других проектов BSD, отчасти потому, что packaging инструменты в ней были полностью переписаны.

Проверьте каталог infrastructure/bin, если вы ищете другие полезные скрипты. Для большинства из них есть man-страницы.

Общие вопросы по поводу инфраструктуры

make(1) в OpenBSD поддерживает ${VAR:U} и ${VAR:L} для преобразования значения переменной в верхний или нижний регистр. Другими словами, make test может быть запущен независимо от регистра. Например:

.if ${NEED_XXX:L} == "yes"
do stuff if yes
.else
do other stuff
.endif

Теоретически, все bool-переменные, распознаваемые bsd.port.mk, всегда должны быть определены, поэтому в констукциях кода наподобее defined(USE_FOO) нет необходимости, и ${USE_FOO:L} != "no" должен работать.

Основной файл bsd.port.mk был сильно оптимизирован и исправлен. В частности, он может выполнять задачи параллельно. Из-за этого была утрачена функция scripts/{pre,do,post}-*. Чтобы снова воспользоваться этой функцией, запустите скрипт вручную из Makefile.

Правильное использование make

Обратите внимание, что если вы запускаете make с параметром (например вот так make VAR=value), присваиваемое значение параметра переопределяет/перезаписывает значение, которое присваивается VAR из Makefile. Это означает, что нет необходимости в множестве патчей для Makefile. Гораздо лучше правильно установить значение MAKE_FLAGS, что к тому же снизит и maintanance нагрузку.

Распаковка (извлечение) исходников

Существует два типа архивов с исходниками: DISTFILES и PATCHFILES. OpenBSD обрабатывает их одинаковым способом и по умолчанию загружает все из MASTER_SITES. Здесь нет ни PATCH_SITES, ни PATCH_SITES_SUBDIR.

Если все загружаемые файлы не принадлежат одному и тому же набору сайтов, OpenBSD разрешает расширение filename:0 до filename:9, и в этом случае для извлечения файлов будет использоваться MASTER_SITES0 вплоть до MASTER_SITES9.

Некоторым платформам могут понадобиться специфичные distfiles. В прошлом это вызывало проблемы, связанные с зеркалированием distfiles. Теперь же OpenBSD поддерживает третий набор файлов: SUPDISTFILES. Они используются только для создания checksums и для зеркалирования (mirroring). Обратите внимание, что SUPDISTFILES может перекрываться DISTFILES или PATCHFILES. Например:

DISTFILES=foo-1.0.tgz
.if ${ARCH} == "i386"
DISTFILES+=foo-i386.tgz
.elif ${ARCHI} == "amd64"
DISTFILES+=foo-amd64.tgz
.endif
SUPDISTFILES=foo-i386.tgz foo-amd64.tgz

Инфраструктура `WRKDIR`

Нам не нужны порты, которые используют NO_WRKDIR. Все порты OpenBSD должны иметь рабочий каталог. Детали, касательно имени рабочего каталога, не должны вызывать беспокойства у того, кто собирает порт. Если вам нужно узнать об этом имени, спросите Makefile:

$ cd that_ports_dir && make show=WRKDIR

Эта команда покажет значение WRKDIR (т.е. имя рабочего каталога) порта.

Основная причина этого запрета заключается в том, что bsd.port.mk в OpenBSD действует как настоящий Makefile с зависимостями. Этап fetch зависит от distfiles и patchfiles, а все остальные этапы зависят от реальных файлов, находящихся в рабочем каталоге, поэтому они не могут существовать без рабочего каталога.

Если DISTFILES extraction является особенным, установите

EXTRACT_ONLY=

и сделайте extraction на этапе post-extract..

WRKDIR: Рабочий каталог порта, куда он помещает свои собственные cookies.
WRKDIST: Подкаталог WRKDIR, куда фактически распаковывается порт. Это также базовый каталог для патча. Другие BSD в настоящее время не имеют WRKDIST/WRKSRC различий и имеют только WRKSRC.
WRKSRC: Подкаталог WRKDIST, в котором фактический находятся исходники.
WRKBUILD: Подкаталог WRKDIR, в котором будут выполняться конфигурирование и сборка порта. Другие BSD не имеют WRKBUILD/WRKSRC различий. Программы, основанные на autoconf (в основном), обычно могут установить SEPARATE_BUILD, чтобы позволить сборке порта происходить в WRKBUILD, отличном от WRKSRC.
WRKCONF: Подкаталог WRKDIR, в котором должны запускаться configure скрипты. По умолчанию используется WRKBUILD, что в 99% случаев верно.
WRKINST: Каталог, в который будет установлен порт перед созданием пакета (читайте о «Fake установке портов» ниже).

Обратите внимание, что NO_WRKSUBDIR был удален: теперь этот же эффект можно достигнуть установив WRKDIST=$(WRKDIR).

Fake установка порта

Введение

После завершения сборки другие BSD приступают к установке порта, а затем собирают пакет из установленного порта. OpenBSD использует fake установку вместо этого.

Порт OpenBSD сконфигурирован и собран как обычно (т.е. установлен в PREFIX, обычно это /usr/local).
Но указывается сдалать установку в другое место, а именно в WRKINST, который обычно является подкаталогом WRKDIR.
Затем из fake установки создается пакет. Происходит это при помощи pkg_create опции -B.
Наконец, получившийся пакет может быть установлен при помощи pkg_add.

Преимущества

Для того, кто собирает пакет (package builder), это означает, что большинство портов не нужно устанавливать на самом деле, что устраняет огромное количество потенциальных проблем с неправильно установленными портами. Это также позволяет создавать несколько конфликтующих пакетов на одном компьютере. Наконец, это позволяет создавать новый набор непроверенных пакетов без правильной установки.
Для того, кто составляет порт (port writer), это значительно упрощает задачу поиска проблем в packing lists, поскольку fake среда пуста до установки порта. Кроме того, если порт устанавливает слишком много файлов, больше нет необходимости настраивать установку порта: достаточно просто не записывать посторонние файлы в packing list.
Для пользователя (end user) это улучшает качество пакетов: поскольку последний порт устанавливается с помощью pkg_add, пользователь получает точно такое же программное обеспечение, которое было подготовлено на машине того, кто собирал порт (porter).

Как это сделать

Цели, используемые для make fake, являются обычными целями для установки, за исключением нескольких отличий:

Вместо MAKE_FLAGS используется FAKE_FLAGS. По умолчанию FAKE_FLAGS устанавливает DESTDIR=${WRKINST}.
Вместо INSTALL_TARGET используется FAKE_TARGET.
Во время выполнения {pre,do,post}-install, значение TRUEPREFIX установлено как $(PREFIX), PREFIX установлено как $(WRKINST)$(PREFIX), а DESTDIR установлено как $(WRKINST).

Порты, использующие imake, должны работать как и обычно, поскольку цели imake настроены на использование DESTDIR. Точно так же недавние порты конфигурации GNU не нуждаются ни в каких изменениях.

Еще один хороший прием - "late binding" («поздняя привязка»): настройте порты на использование prefix со значением $(DESTDIR)/usr/local, чтобы получившийся Makefile имел следующую конфигурацию:

prefix=$(DESTDIR)/usr/local

Когда порт начинает собираться при пустом значении DESTDIR, будет использоваться /usr/local. Fake установка поместит все в ${WRKINST}/usr/local (например, для GNU configure используйте CONFIGURE_STYLE= gnu dest).

Ловушки

Некоторые порты несовместимы с изменениями значения своего DESTDIR: для бОльшей части порта это не будет проблемой, за исключением одного или двух нарушителей. Исправьте проблему (Patch the problem away).
Будьте внимательны и отслеживайте фактическое местоположение, в котором установлен порт, и местоположение, используемое конфигами пакета. Это очень легко пропустить, но легко исправить при помощи TRUEPREFIX.
Абсолютные symlinks всегда нужно настраивать. К счастью, bsd.port.mk заметит проблемы в этой области.
Некоторые порты не хотят оставлять в покое $(DESTDIR) на этапе настройки. Тут понадобится post-configure, который добавляет DESTDIR настройки во все Makefile-файлы.
Очень редко порт сопротивляется всем разумным попыткам использовать FAKE. Подход грубой силы работает тут на ура: используйте pre-fake, чтобы слинковать или скопировать все, что порт хочет найти в WRKINST, затем выполните install в chroot.

Packaging инструменты

Инструменты пакета знают о довольно многих типах файлов и могут делать многое автоматически: в большинстве случаев команды @exec или скрипты INSTALL не нужны.

Обратите внимание, что все ненужные скрипты должны быть заблокированы, так как они имеют проблемы с масштабируемостью. Гораздо проще отлаживать инфраструктуру одного пакета, чем модифицировать сотни скриптов для решения новых проблем. Например:

@exec ldconfig не нужен, поскольку shared libraries упоминаются как @lib libfoo.so.1.0, а ldconfig запускается только при необходимости и корректно обрабатывает chroot.
@exec install-info не нужен, поскольку файлы документации info упоминаются как @info file.info. Благодаря этому нет проблем и с составными info файлами, а также отпадает необходимость в запуске makeinfo --no-split.
шрифты (fonts) интегрируются автоматически благодаря @font и @fontdir.
Новые пользователи и группы создаются при помощи @newuser и @newgroup вместо installation скриптов. Они создаются достаточно рано, чтобы их можно было использовать в процессе дальнейшего extraction пакета.
Большинство third party баз данных обрабатываются при помощи @tag, который запускает такие инструменты как update-desktop-database в конце установки.
Файлы конфигурации обрабатываются при помощи @sample вместо installation скриптов.

Прочитайте pkg_create(1), где содержится более подробная информация по этой теме. В большинстве случаев, make update-plist создаст очень хорошую приблизительную картину того, что должно быть в packing-list и скопирует настройки из одной версии в другую (следующую).

Flavors

Параметры сборки были организованны (рационализированы) в виде Flavors, так что сборка пакетов теперь может быть последовательной. Порт с параметрами должен установить FLAVORS в качестве списка всех параметров, которые имеют смысл для этого порта (например, FLAVORS=foo bar zoinx), а затем использовать FLAVOR, чтобы проверить, какие параметры фактически были выбраны (например, FLAVOR=zoinx foo). bsd.port.mk предоставляет тут некоторую поддержку:

PKGNAME настроен для включения опций, разделенных дефисом (например, package-foo-zoinx).
WRKDIR настроен таким образом, что различные flavors могут собираться одновременно, не мешая при этом друг другу.
Конструкции вида %%flavor%% вызовут включение PFRAG.flavor.
bsd.port.subdir.mk понимает расширение SUBDIR=directory,opt1,opt2 и интерпретирует его как «надо собрать порт в directory с FLAVOR=opt1 opt2».

Проверить, что тот или иной flavor был выбран для сбоки, можно следующим образом:

.if ${FLAVOR:Mzoinx}

Существует дополнительное расширение, известное как MULTI_PACKAGES. Вообще говоря, MULTI_PACKAGES и FLAVORS являются противоположными механизмами. Вместе их количество в дереве портов OpenBSD несколько меньше, чем в другиех BSD, поскольку они позволяют из одного порта создавать много разных пакетов. bsd.port.mk(5) имеет целый раздел, посвященный FLAVORS и MULTI_PACKAGES.