3.1. Создание файла Makefile

Минимальный Makefile будет выглядеть примерно так:

# New ports collection makefile for:   oneko
# Date created:        5 December 1994
# Whom:            asami
#
# $FreeBSD$
#

PORTNAME=      oneko
PORTVERSION=   1.1b
CATEGORIES=    games
MASTER_SITES=  ftp://ftp.cs.columbia.edu/archives/X11R5/contrib/

MAINTAINER=    asami@FreeBSD.org

MAN1=          oneko.1
MANCOMPRESSED= yes
USE_IMAKE=     yes

.include <bsd.port.mk>

Посмотрим, сможете ли вы его понять. Не обращайте внимание на содержимое строчки $FreeBSD$, она будет заполнена автоматически системой CVS, когда порт будет импортирован в наше дерево портов. Вы можете найти более подробный пример в разделе пример Makefile.

3.2. Создание информационных файлов

Имеется два информационных файла, которые требуются для любого порта, вне зависимости от того, является ли он пакетом или нет. Это pkg-descr и pkg-plist. Префикс pkg- отличает их от других файлов.

This is a port of oneko, in which a cat chases a poor mouse all over
the screen.
 :
(etc.)

WWW: http://www.oneko.org/

- Satoshi
asami@cs.berkeley.edu

bin/oneko
lib/X11/app-defaults/Oneko
lib/X11/oneko/cat1.xpm
lib/X11/oneko/cat2.xpm
lib/X11/oneko/mouse.xpm
@dirrm lib/X11/oneko

PLIST_FILES=   bin/oneko \
        lib/X11/app-defaults/Oneko \
        lib/X11/oneko/cat1.xpm \
        lib/X11/oneko/cat2.xpm \
        lib/X11/oneko/mouse.xpm
PLIST_DIRS= lib/X11/oneko

3.3. Создание файла с контрольной суммой

Просто введите команду make makesum. Правила утилиты make автоматически сгенерируют файл distinfo.

3.4. Тестирование порта

Вы должны удостовериться, что правила построения порта выполняют именно то, что вы хотите, включая создание пакета для порта. Вот те важные вещи, которые вы должны проверить.

• pkg-plist не содержит ничего сверх того, что устанавливается вашим портом

• pkg-plist содержит абсолютно все, что устанавливается вашим портом

• Ваш порт может быть переустановлен множество раз с помощью указания цели reinstall

• Ваш порт подчищает за собой после своего удаления

Проверьте, что ни на шаге package, ни на шаге deinstall не выдается никаких предупреждений. После выполнения шага 3 проверьте, что все новые каталоги были успешно удалены. Также попробуйте запустить программное обеспечение после выполнения шага 4, чтобы убедиться, что оно работает правильно при установке из пакета.

3.5. Проверка вашего порта утилитой portlint

Будьте добры, пользуйтесь утилитой portlint для проверки того, что ваш порт соответствует нашим рекомендациям. Программа portlint является частью Коллекции Портов. В частности, вы можете захотеть проверить, правильно ли сформирован файл Makefile и соответствующим ли образом наименован пакет.

3.6. Посылка порта

Первым делом удостоверьтесь, что вы прочитали раздел о том, что можно и нельзя делать.

Теперь, когда вы счастливы от своего первого порта, единственное, что осталось сделать, это включить его в основное дерево портов FreeBSD и осчастливить этим всех остальных. Нам не нужен ни ваш каталог work, ни пакет pkgname.tgz, так что удалите их прямо сейчас. Затем просто включите вывод команды shar `find port_dir` в сообщение об ошибке и пошлите его с помощью программы send-pr(1) (обратитесь к разделу Сообщения об ошибках и общие замечания для получения подробной информации о программе send-pr(1)). Если размер неупакованного порта превышает 20КБ, то сожмите его в tar-файл и воспользуйтесь утилитой uuencode(1) перед тем, как включить его в сообщение (можно посылать такие файлы, даже если сообщение не превышают 20КБ, но это не рекомендуется). Не забудьте указать в сообщении категорию ports и класс change-request (Не указывайте, что сообщение имеет статус confidential!). Добавьте также краткое описание программы, порт которой вы создали, в раздел ``Description'' отправляемого PR и сам порт в виде архива shar или архива tar, обработанного утилитой uuencode, поместив его в раздел ``Fix''.

Повторим ещё раз, что не нужно включать ни оригинальный файл с дистрибутивом, ни каталог work, ни пакет, построенный вами командой make package.

После того как вы послали порт, пожалуйста, потерпите. Иногда включение нового порта может занять до нескольких месяцев, а иногда всего несколько дней. Здесь вы можете найти список портов ожидающих своей очереди для включения во FreeBSD.

Мы рассмотрим ваш порт, при необходимости вернём его обратно, а затем включим порт в наше дерево. Ваше имя также появится в списке Дополнительных контрибуторов проекта FreeBSD и других файлах. Разве это не великолепно?!? :-)

4.1. Как всё это работает

Во-первых, когда пользователь дает в своем каталоге с портом команду make, происходит целая череда событий. Во время чтения этого текста может оказаться полезным иметь файл bsd.port.mk открытым в другом окне, что сильно поможет в их понимании.

Но не волнуйтесь сильно, если вы не до конца понимаете, что делается в bsd.port.mk, не так уж много людей его понимает... :->

Выше перечислены стандартные действия. Кроме того, вы сами можете определить цели pre-что-то или post-что-то, или создать скрипты с такими именами в подкаталоге scripts, и они будут запущены до или после выполнения действий по умолчанию.

Например, если у вас есть цель post-extract, определённая в вашем файле Makefile и файл pre-build в подкаталоге scripts, то после выполнения обычных действий по распаковке, будет вызвана цель post-extract а скрипт pre-build будет выполнен перед запуском стандартных правил построения. Рекомендуется использовать цели из Makefile, если действия достаточно просты, потому что в дальнейшем будет проще определить, какие нестандартные действия требует порт.

Действия по умолчанию выполняются целями do-что-то из bsd.port.mk. Например, команды для распаковки порта находятся в цели do-extract. Если вам не хватает цели по умолчанию, вы можете ее исправить, переопределив цель do-something в вашем файле Makefile.

Теперь вы представляете, что происходит, когда пользователь набирает команду make, теперь давайте пройдемся через шаги, рекомендуемые для создания настоящего порта.

4.2. Получение исходного кода

Получите оригинальные исходные тексты (обычно) в виде упакованного tar-архива (foo.tar.gz или foo.tar.Z) и скопируйте его в каталог DISTDIR. Всегда используйте исходные тексты основной ветки разработки везде, где это возможно.

Вам потребуется задать значение переменной MASTER_SITES так, чтобы оно указывало на местоположение оригинального tar-архива. В файле bsd.sites.mk вы найдёте краткие обозначения для большинства популярных сайтов. Пожалуйста, используйте эти сайты--и соответствующие определения--везде, где это возможно, чтобы избежать проблем повторения одной и той же информации в базе источников. Так как эти сайты со временем меняются, для всех причастных поддержка становится настоящим кошмаром.

Если вы не можете найти FTP/HTTP сайт с хорошим подключением к сети, или находите только сайты, которые имеют раздражающе нестандартные форматы, то можете захотеть поместить копию на надежный сервер FTP или HTTP, который вам доступен (например, ваша домашняя страница).

Если вы не можете найти доступного и надёжного места для помещения дистрибутивного файла, то мы сами сможем разместить его на сервере ftp.FreeBSD.org; однако это наименее рекомендуемое решение. Дистрибутивный файл должен быть помещён в каталог ~/public_distfiles/ одного из пользователей машины freefall. Попросите того, кто коммиттил ваш порт, сделать это. Этот человек также задаст переменной MASTER_SITES значение MASTER_SITE_LOCAL, а в переменной MASTER_SITE_SUBDIR укажет своё имя пользователя с машины freefall.

Если дистрибутивные файлы вашего порта постоянно меняются по неизвестным причинам без изменения версий со стороны автора, остаётся только поместить дистрибутив на вашу домашнюю Web-страницу и указать её первой в списке MASTER_SITES. Если можете, попытайтесь договориться с автором порта об этом; это действительно помогает в достижении некоторого управления исходным кодом. Хостирование собственной версии поможет избежать появления ошибок у пользователей типа “checksum mismatch”, а также уменьшит нагрузку на людей, сопровождающих наш FTP-сервер. Также, если у порта имеется только один основной сервер, то рекомендуется поместить архивную копию на свой сайт и указать его в списке MASTER_SITES вторым.

Если вашему порту требуются дополнительные `патчи', доступные в Интернет, скачайте также и их, поместив в каталог DISTDIR. Не волнуйтесь, если они находятся не на том же сайте, откуда взят дистрибутивный архив, мы умеем обрабатывать такие ситуации (смотрите описание PATCHFILES ниже).

4.3. Модификация порта

Распакуйте копию дистрибутивного файла в отдельный каталог и внесите изменения, которые необходимы для того, чтобы порт компилировался нормально в текущей версии FreeBSD. Тщательно отслеживайте все, что вы делаете, этот процесс вам предстоит автоматизировать. Все, включая удаление, добавление или модификацию в файлах должны будут выполняться автоматически с помощью скриптов или файлов патчей, когда вы завершите работу над портом.

Если вашему порту во время компиляции, установки и настройки требуется довольно много взаимодействовать с пользователем, то посмотрите на один из классических скриптов Configure Лэрри Уолла (Larry Wall) и сделайте сами что-либо подобное. Предназначение новой коллекции портов - это сделать каждое приложение в стиле ``plug-and-play'' настолько, насколько это вообще возможно для конечного пользователя при минимальном использовании дискового пространства.

4.4. Создание патчей

Файлы, которые добавлялись или изменялись в процессе создания порта, могут быть выявлены вызовом программы diff(1) с рекурсией, а результат работы этой программы может быть в дальнейшем передан программе patch(1). Каждый набор патчей, который вы собираетесь применить, должен быть собран в файл с именем patch-*, где * означает порядок, в которой будут применяться патчи -- это делается в алфавитном порядке, то есть сначала aa, затем ab и так далее. Если хотите, вы можете использовать имена файлов, указывающие на имена файлов, к которым применяются патчи, такие, как patch-Imakefile или patch-src-config.h. Эти файлы должны находиться в каталоге PATCHDIR, откуда они будут взяты автоматически. Все патчи должны быть сделаны относительно каталога WRKSRC (как правило, это каталог, в который распаковывается исходный архив и где будет выполняться построение). Для упрощения внесения изменений и обновлений вы должны избегать наличия более чем одного патча для одного и того же файла (например, патчей patch-aa и patch-ab, оба меняющих файл WRKSRC/foobar.c).

Не помещайте строки RCS в патчи. CVS будет изменять их при помещении файлов в дерево портов, и когда мы будем их оттуда извлекать, они будут уже другие, поэтому применение патчей окончится неудачей. Строчки RCS предваряются знаком доллара ($), и обычно начинаются с $Id или $RCS.

Использование параметра рекурсии (-r) с командой diff(1) для генерации патчей - это хорошо, но всё же, пожалуйста, смотрите на получающиеся патчи, чтобы убедиться в отсутствии ненужного мусора. В частности, diff-разниц между двумя резервными копиями файлов, файлы Makefile, когда как порт использует Imake или GNU-версию программы configure, и так далее, не нужны, и должны быть удалены. Если вы отредактировали файл configure.in и запустили autoconf для перегенерации configure, не нужно включать файлы diff для configure (они частенько вырастают до нескольких тысяч строк!); задайте USE_AUTOCONF_VER=213 и включите diff-файл для configure.in.

Кроме того, если вы удаляете файл, то это можно сделать и в цели post-extract, а не внутри патча. Как только вы будете удовлетворены получающимся diff-файлом, разбейте его на несколько по одному патчу на отдельный файл.

4.5. Конфигурирование

Поместите все дополнительные команды, требуемые для настройки, в ваш скрипт configure и сохраните его в подкаталоге scripts. Как отмечено выше, вы можете сделать это целями в файле Makefile и/или скриптами с именами pre-configure или post-configure.

4.6. Обработка пользовательского ввода

Если для построения, конфигурации или установки вашего порта требуется некоторый ввод со стороны пользователя, то вы должны задать переменную IS_INTERACTIVE в вашем файле Makefile. В случае ``ночного построения'' это позволит пропустить ваш порт, если пользователь в своем окружении задал переменную BATCH (и если пользователь установил переменную INTERACTIVE, то будут строиться только порты, которые требуют взаимодействия с пользователем. Это сэкономит значительное количество времени на части машин, которые постоянно строят порты (смотрите ниже).

При наличии разумных ответов на задаваемые вопросы, подходящих по умолчанию, также рекомендуется проверять переменную PACKAGE_BUILDING и выключать интерактивный скрипт, если он есть. Это позволит нам строить пакеты для помещения на компакт-диски и FTP-серверы.

5.1. Оригинальные исходный код

Находится ли он в каталоге DISTDIR в виде стандартного упакованного архиватором gzip tar-архива с именем типа foozolix-1.2.tar.gz? Если это так, можно перейти к следующему шагу. Если нет, то вы должны попытаться переопределить некоторые из переменных DISTNAME, EXTRACT_CMD, EXTRACT_BEFORE_ARGS, EXTRACT_AFTER_ARGS, EXTRACT_SUFX или DISTFILES в зависимости от того, насколько необычен формат дистрибутивного файла. (Самый распространённый случай - это EXTRACT_SUFX=.tar.Z, когда tar-файл упакован обычной утилитой compress, а не архиватором gzip.)

В худшем случае вы можете просто определить свою собственную цель do-extract для переопределения действий по умолчанию, хотя к этому нужно будет прибегать в очень редких случаях, если вообще придётся.

5.2. Именование

В первой части Makefile порта ему даётся название, указывается его номер версии и принадлежность к правильной категории.

PORTNAME=      gtkmumble
PORTVERSION=   0.10

PORTNAME=      gtkmumble
PORTVERSION=   0.10
PORTREVISION=  1

PORTNAME=      gtkmumble
PORTVERSION=   0.2
PORTEPOCH=     1

PORTNAME=      gtkmumble
PORTVERSION=   0.3
PORTEPOCH=     1

5.3. Разделение по категориям

5.4. Дистрибутивные файлы

Во второй части Makefile задаётся, какие файлы и откуда должны быть сгружены для того, чтобы построить порт.

MASTER_SITES=        ${MASTER_SITE_XCONTRIB}
MASTER_SITE_SUBDIR=   applications

DISTNAME=      foo
EXTRACT_SUFX=  .tgz

DISTFILES=     source1.tar.gz source2.tar.gz

DISTFILES=     source.tar.gz manual.html
EXTRACT_ONLY=  source.tar.gz

EXTRACT_ONLY=

DISTFILES=      alpha:0 beta:1

MASTER_SITES=   ftp://ftp.example1.com/:source1 \
                ftp://ftp.example2.com/:source2
DISTFILES=      source1.tar.gz:source1 \
                source2.tar.gz:source2

MASTER_SITES=   ftp://ftp.example1.com/:source1 \
                ftp://ftp.example2.com/:source2
DISTFILES=      source1.tar.gz:source1 \
                source2.tar.gz:source2 \
                source3.tar.gz:source2

5.5. MAINTAINER

Укажите здесь ваш адрес электронной почты. Пожалуйста. :-)

Заметьте, что в качестве значения для MAINTAINER допустимо использование только одного адреса без поля комментария. Должен использоваться формат user@hostname.domain. Пожалуйста, не включайте никакого описательного текста, например, вашего настоящего имени в эту строку--это несколько сбивает с толку bsd.port.mk. Вместо этого помещайте такую информацию в ваш pkg-descr.

Подробное описание того, за что отвечает лицо, поддерживающее порт, даётся в главе MAINTAINER в Makefiles.

Если мейнтейнер порта не ответил на запрос пользователя об обновлении в течение двух недель (исключая большие праздники), то это можно считать тайм-аутом от мейнтейнера, и обновление может быть выполнено без явного подтверждения от мейнтейнера. Если мейнтейнер не отвечает в течение трёх месяцев, то считается, что он отсутствует, и как мейнтейнер порта, о котором идёт речь, может быть заменён. Исключениями из этого правила является всё, что сопровождает Группа Менеджеров Дерева Портов FreeBSD <portmgr@FreeBSD.org> или Группа Офицеров Безопасности <security-officer@FreeBSD.org>. Запрещено делать любые несанкционированные изменения в портах, которые ведут эти группы.

За Группа Менеджеров Дерева Портов FreeBSD <portmgr@FreeBSD.org> оставляется право снять или назначить кого-либо мейнтейнером, по любой причине, а за the Группа Офицеров Безопасности <security-officer@FreeBSD.org> оставляется право лишать или назначать права на сопровождение порта по соображениям информационной безопасности.

5.6. COMMENT

Это однострочное описание порта. Пожалуйста, не включайте сюда название пакета (или номер версии программного обеспечения). Комментарий должен начинаться с заглавной буквы и не заканчиваться точкой. Вот пример:

A cat chasing a mouse all over the screen

В файле Makefile переменная COMMENT должна следовать сразу за переменной MAINTAINER.

Пожалуйста, постарайтесь делать строку COMMENT длиной, меньшей, чем 70 символов, так как она выдаётся пользователям в качестве однострочного описания порта.

5.7. Зависимости

Многие порты зависят от других портов. Имеется семь переменных, которые вы можете использовать для обеспечения того, что всё требуемое находится на машине пользователя. Имеется также несколько предопределённых переменных, отражающих зависимости для общих случаев, плюс ещё несколько для управления поведением зависимостей.

 LIB_DEPENDS=
      jpeg.9:${PORTSDIR}/graphics/jpeg:install

RUN_DEPENDS=   ${LOCALBASE}/etc/innd:${PORTSDIR}/news/inn \
           wish8.0:${PORTSDIR}/x11-toolkits/tk80
   

 BUILD_DEPENDS=
      unzip:${PORTSDIR}/archivers/unzip

 FETCH_DEPENDS=
      ncftp2:${PORTSDIR}/net/ncftp2

EXTRACT_DEPENDS=
          unzip:${PORTSDIR}/archivers/unzip

PATCH_DEPENDS=
          ${NONEXISTENT}:${PORTSDIR}/java/jfc:extract

BUILD_DEPENDS=   ${NONEXISTENT}:${PORTSDIR}/graphics/jpeg:extract

5.8. Задание рабочего каталога

Каждый порт распаковывается в рабочий каталог, который должен быть доступным для записи. В системе портов по умолчанию DISTFILES распаковываются в каталог с именем ${DISTNAME}. Другими словами, если вы задали:

PORTNAME=      foo
PORTVERSION=   1.0

то дистрибутивные файлы порта содержат каталог верхнего уровня, foo-1.0, и все файлы расположены в этом каталоге.

Если это не ваш случай, то имеется несколько переменных, которые вы можете переопределить.

WRKSRC=      ${WRKDIR}/foo

WRKSRC=      ${WRKDIR}/${PORTNAME}

NO_WRKSUBDIR= yes

5.9. CONFLICTS

Если ваш пакет не может существовать одновременно с другими (из-за конфликтов файлов, несовместимости во время выполнения и так далее), перечислите имена остальных пакетов в переменной CONFLICTS. Здесь вы можете использовать шаблоны командного процессора типа * и ?. Имена пакетов должны выглядеть так же, как в /var/db/pkg. Пожалуйста, убедитесь, что CONFLICTS не содержит пакет самого этого порта или еще, что установка с помощью переменной FORCE_PKG_REGISTER больше не будет использоваться.

5.10. Механизмы построения

Если ваш пакет использует GNU-версию утилиты make, задайте USE_GMAKE=yes. Если ваш пакет использует configure, задайте HAS_CONFIGURE=yes. Если ваш пакет использует GNU-версию configure, задайте GNU_CONFIGURE=yes (это также подразумевает HAS_CONFIGURE). Если вы хотите передать дополнительные параметры в configure (список параметров представляет собой --prefix=${PREFIX} для GNU configure и пустую строку для не-GNU configure), укажите эти дополнительные параметры в CONFIGURE_ARGS. Если ваш пакет использует GNU-версию autoconf, задайте USE_AUTOCONF_VER=213. Это подразумевает GNU_CONFIGURE, и приведет к вызову autoconf до запуска configure.

Если ваш пакет является приложением для X, которое создает файлы Makefile из соответствующих файлов Imakefile при помощи утилиты imake, то задайте USE_IMAKE=yes. Это приведет к автоматическому запуску команды xmkmf -a на этапе конфигурирования. Если использование флага -a является для вашего порта проблематичным, задайте XMKMF=xmkmf. Если порт использует команду imake, но не воспринимает цель install.man, то должна быть задана переменная NO_INSTALL_MANPAGES=yes. Кроме того, автор программы должен быть пристрелен. :->

Если в файле Makefile из дистрибутива вашего порта в качестве главной цели для построения указано нечто, отличное от all, то задайте соответствующим образом переменную ALL_TARGET. То же самое касается целей install и INSTALL_TARGET.

6.1. Динамические библиотеки

Если ваш порт устанавливает одну или несколько динамических библиотек, определите переменную INSTALLS_SHLIB, которая приведёт к запуску из bsd.port.mk команды ${LDCONFIG} -m относительно каталога, в который устанавливается новая библиотека (как правило, это PREFIX/lib), во время выполнения цели post-install для её регистрации в кэше динамических библиотек. Эта переменная, если она определена, также приведёт к добавлению соответствующей пары команд @exec /sbin/ldconfig -m и @unexec /sbin/ldconfig -R в ваш файл pkg-plist, так что пользователь, устанавливающий пакет, сможет сразу же использовать динамическую библиотеку, а удаление пакета не приведёт к тому, что система будет предполагать, что библиотека всё ещё имеется в наличии.

Если нужно, вы можете переопределить каталог, в который по умолчанию устанавливается библиотека, задав переменную LDCONFIG_DIRS, в которой должны быть перечислены каталоги, в которые устанавливаются динамические библиотеки. Например, если ваш порт устанавливает динамические библиотеки в каталоги PREFIX/lib/foo и PREFIX/lib/bar, то вы можете в файле Makefile указать следующее:

INSTALLS_SHLIB= yes
LDCONFIG_DIRS=  %%PREFIX%%/lib/foo %%PREFIX%%/lib/bar

Заметьте, что значение переменной LDCONFIG_DIRS передаётся через sed(1), как и всё остальное в pkg-plist, так что подстановка значения PLIST_SUB также происходит здесь. Рекомендуется использовать %%PREFIX%% для PREFIX, %%LOCALBASE%% для LOCALBASE и %%X11BASE%% для X11BASE.

6.2. Порты с ограничениями на распространение

Лицензии бывают разных видов, и некоторые накладывают ограничение на то, как приложение может быть оформлено в виде пакета, может ли оно продаваться для извлечения коммерческой выгоды, и так далее.

В подобных ситуациях можно использовать переменные, описываемые в последующих разделах.

6.3. Использование perl

6.4. Использование X11

6.5. Использование automake, autoconf и libtool

6.6. Использование GNOME

Для задания того, какие компоненты GNOME использует конкретный порт, проект FreeBSD/GNOME использует собственный набор переменных. На странице проекта FreeBSD/GNOME размещён исчерпывающий список этих переменных.

6.7. Использование KDE

6.8. Использование Bison

Этот раздел ещё предстоит написать.

6.9. Использование Java

PLIST_FILES+= ${JAVAJARDIR:S,^${PREFIX}/,,}/myport.jar

6.10. Использование Python

Этот раздел ещё предстоит написать.

6.11. Использование Emacs

Этот раздел ещё предстоит написать.

6.12. Использование Ruby

Этот раздел ещё предстоит написать.

6.13. Использование SDL

Переменная USE_SDL используется для автоматической настройки зависимостей для портов, использующих библиотеки на основе SDL, такие как devel/sdl12 или x11-toolkits/sdl_gui.

На данный момент распознаются следующие SDL-библиотеки:

• sdl: devel/sdl12

• gfx: graphics/sdl_gfx

• gui: x11-toolkits/sdl_gui

• image: graphics/sdl_image

• ldbad: devel/sdl_ldbad

• mixer: audio/sdl_mixer

• mm: devel/sdlmm

• net: net/sdl_net

• sound: audio/sdl_sound

• ttf: graphics/sdl_ttf

Таким образом, если порт имеет зависимость от net/sdl_net и audio/sdl_mixer, то строка будет следующей:

USE_SDL=   net mixer

Зависимость от порта devel/sdl12, который требуется для net/sdl_net и audio/sdl_mixer будет также автоматически добавлен.

Если вы используете USE_SDL, то он автоматически:

• Добавляет зависимость от sdl12-config к BUILD_DEPENDS

• Добавляет переменную SDL_CONFIG к CONFIGURE_ENV

• Добавляет зависимости от указанных библиотек к LIB_DEPENDS

Для проверки наличия библиотеки SDL вы можете делать это при помощи переменной WANT_SDL:

WANT_SDL=yes

.include <bsd.port.pre.mk>

.if ${HAVE_SDL:Mmixer}!=""
USE_SDL+=   mixer
.endif

.include <bsd.port.post.mk>

10.1. USE_MOTIF

Если вашему порту требуется Motif, задайте эту переменную в файле Makefile. Это не позволит людям, у которых нет собственной копии Motif, даже попытаться построить порт.

10.2. MOTIFLIB

Эта переменная будет установлена сценарием bsd.port.mk в соответствующее значение, соответствующее библиотеке Motif. Пожалуйста, измените исходные тексты вашего порта на использование этой переменной там, где упоминается библиотека Motif, в Makefile или Imakefile.

Могут быть два случая:

• Ели порт обращается к библиотеке Motif как -lXm в своих файлах Makefile или Imakefile, просто подставьте вместо этих обращений ${MOTIFLIB}.

• Если порт использует XmClientLibs в своем файле Imakefile, измените это обращение на ${MOTIFLIB} ${XTOOLLIB} ${XLIB}.

Заметьте, что переменная MOTIFLIB (как правило) раскрывается в -L/usr/X11R6/lib -lXm или /usr/X11R6/lib/libXm.a, так что нет нужды впереди добавлять -L или -l.

13.1. pkg-message

Если вам нужно вывести сообщение для человека, устанавливающего приложение, то вы можете поместить сообщение в файл pkg-message. Эта возможность часто оказывается полезной для вывода дополнительных шагов установки, которые нужно предпринять после выполнения команды pkg_add(1), или для вывода информации о лицензировании.

13.2. pkg-install

Если при установке бинарного пакета по команде pkg_add(1) вашему порту нужно выполнить какие-то дополнительные действия или команды, то вы можете сделать это с помощью скрипта pkg-install. Этот скрипт будет автоматически добавлен к пакету, и будет дважды запускаться по команде pkg_add(1): первый раз в виде ${SH} pkg-install ${PKGNAME} PRE-INSTALL, а второй раз как ${SH} {PKGNAME} POST-INSTALL. Для распознавания того, в каком режиме запущен скрипт, можно использовать параметр $2. Переменная окружения PKG_PREFIX будет принимать значение, соответствующее каталогу, в который устанавливается пакет. Дополнительная информация находится на странице Справочника о команде pkg_add(1).

13.3. pkg-deinstall

Этот скрипт вызывается при удалении пакета.

Этот скрипт утилитой pkg_delete(1) будет запускаться дважды. Первый раз как ${SH} pkg-install ${PKGNAME} DEINSTALL, а второй раз как ${SH} pkg-install ${PKGNAME} POST-DEINSTALL.

13.4. pkg-req

Если вашему порту нужно определять, должен ли он устанавливаться или нет, то вы можете создать скрипт ``необходимости'' pkg-req. Он будет вызван автоматически в момент установки/удаления для определения того, должны ли они реально выполняться.

Скрипт будет запущен в процессе установки командой pkg_add(1), как pkg-req ${PKGNAME} INSTALL. В процессе удаления он будет запущен командой pkg_delete(1) как pkg-req ${PKGNAME} DEINSTALL.

13.5. Изменение содержимого pkg-plist в зависимости от make-переменных

Некоторые порты, в частности, порты p5-, должны менять содержимое своих файлов pkg-plist в зависимости от того, с какими параметрами они были отконфигурированы (или в зависимости от версии языка perl в случае портов p5-). Чтобы облегчить этот процесс, любые вхождения ключевых слов %%OSREL%%, %%PERL_VER%% и %%PERL_VERSION%% в файле pkg-plist будут заменяться соответствующими значениями. Значением %%OSREL%% является номер версии операционной системы (например, 4.9). %%PERL_VERSION%% обозначает полный номер версии perl (например, 5.00502), а %%PERL_VER%% - номер версии perl без номера патча (например, 5.005).

Если вам нужно сделать другие подстановки, вы можете указать в переменной PLIST_SUB список пар VAR=VALUE, и все вхождения %%VAR%% в файле pkg-plist будут заменяться на значение VALUE.

Например, если у вас имеется порт, который устанавливает много файлов в каталог, зависящий от версии, вы можете задать нечто типа

OCTAVE_VERSION= 2.0.13
PLIST_SUB=  OCTAVE_VERSION=${OCTAVE_VERSION}

Эта подстановка (также, как и добавление любых справочных страниц) будет сделана между выполнением целей pre-install и do-install, посредством чтения файла PLIST и записью в файл TMPPLIST (по умолчанию это файл WRKDIR/.PLIST.mktmp). Так что если ваш порт строит PLIST на лету, делайте это во время или до выполнения цели pre-install. Кроме того, если вашему порту требуется отредактировать получающийся файл, делайте это в цели post-install изменением файла TMPPLIST.

Другой способ изменения списка сборки порта основан на определении значений переменных PLIST_FILES и PLIST_DIRS. Каждое из них рассматривается как перечень путей для записи в TMPPLIST содержимого PLIST. Имена, перечисленные в PLIST_FILES и PLIST_DIRS, подвергаются подстановке %%VAR%%, как описано выше. За исключением этого, имена из PLIST_FILES будут появляться в окончательном варианте перечня сборки без изменений, когда как @dirrm будет предшествовать именам из PLIST_DIRS. Для того, чтобы возыметь действие, PLIST_FILES и PLIST_DIRS должны задаваться до того, как будет записываться TMPPLIST, то есть в цели pre-install или ещё раньше.

13.6. Изменение имён файлов pkg-*

Все имена файлов pkg-* определяются с помощью переменных, так что вы можете изменить их, если это нужно, в вашем файле Makefile. Это особенно полезно, если вы используете одни и те же файлы pkg-* совместно между несколькими портами или пишете в один из вышеперечисленных файлов (в главе о записи в каталоги, отличные от WRKDIR объяснено, почему не рекомендуется осуществлять запись непосредственно в файлы pkg-*.

Вот список имён переменных и их значений по умолчанию. (Значение PKGDIR по умолчанию равно ${MASTERDIR}.)

Пожалуйста, изменяйте значения этих переменных, а не переопределяйте PKG_ARGS. Если вы измените значение переменных PKG_ARGS, то эти файлы при установке из порта будут установлены в каталог /var/db/pkg некорректно.

14.1. Запуск make describe

Некоторые утилиты FreeBSD для сопровождения портов, например, portupgrade(1), опираются на базу данных с именем /usr/ports/INDEX, в которой отслеживаются такие характеристики портов, как их зависимости. Файл INDEX создаётся при помощи ports/Makefile верхнего уровня по команде make index, спускающейся в подкаталог каждого порта и выполняющей в нём make describe. Таким образом, если выполнение make describe с каким-либо портом завершится неудачно, то никому не удастся создать INDEX, при этом много людей вскоре станут несчастны.

USE_POINTYHAT=yes

.if USE_POINTYHAT
.error "POINTYHAT is not supported"
.endif

.if USE_POINTYHAT
IGNORE=POINTYHAT is not supported
.endif

Если команда make describe выдаёт строчку, а не ошибку, то для вас это пройдёт безболезненно. Обратитесь к файлу bsd.port.mk, чтобы выяснить значение выдаваемых строк.

Заметьте также, что запуск последней версии portlint (как указано в следующем разделе) приведёт к автоматическому запуску команды make describe.

14.2. Portlint

Проверьте свою работу командой portlint перед тем, как её отослать или перенести в дерево портов. portlint предупреждает вас о многих распространённых ошибках, как функциональных, так и стилистических. Для нового (или скопированного внутри хранилища) порта самым подходящим является запуск portlint -A; для уже существующего порта достаточно будет запустить portlint -C.

Так как для обнаружения ошибок portlint использует эвристические методы, то им могут выдаваться и ошибочные предупреждения. Кроме того, время от времени нечто, отмечаемое как некорректность, из-за ограничений механизма создания портов не может быть сделано никак иначе. Если вы сомневаетесь, то лучше всего спросить в Список рассылки, посвящённый Портам FreeBSD.

14.3. PREFIX

Попытайтесь сделать так, чтобы установка вашего порта осуществлялась относительно каталога PREFIX. (Значение этой переменной будет установлено в LOCALBASE (по умолчанию /usr/local), если только не заданы переменные USE_X_PREFIX или USE_IMAKE, в случае чего он будет принят равным X11BASE (по умолчанию /usr/X11R6).

Избежание явного указания /usr/local или /usr/X11R6 в исходном коде сделает порт гораздо более гибким и способным удовлетворить потребности других серверов. Для портов, которые используют X, это происходит автоматически; в противном случае зачастую это может быть сделано простой заменой строк /usr/local (или /usr/X11R6 для портов X, не использующих imake) в различных файлах scripts/Makefile порта на использование ${PREFIX}, так как эта переменная автоматически передаётся далее на каждом этапе построения и установки.

Проверьте, что ваше приложение не устанавливает чего-либо в каталог /usr/local вместо PREFIX. Это можно быстро проверить следующим образом:

# make clean; make package PREFIX=/var/tmp/port-name

Если что-то было установлено за пределами PREFIX, то процесс создания пакета сообщит об отсутствии файлов.

Здесь не проверяется ни наличие внешних ссылок, ни корректность использования LOCALBASE в качестве ссылки на файлы из других портов. Проверка установки в каталог /var/tmp/port-name делает это.

Не задавайте переменную USE_X_PREFIX до тех пор, пока она на самом деле не понадобится для порта (то есть он будет скомпонован с библиотеками X или нужно будет обращаться к файлам из X11BASE).

Переменная PREFIX может быть переназначена в вашем файле Makefile или в окружении пользователя. Однако строго не рекомендуется отдельным портам устанавливать эту переменную явно в файлах Makefile.

Кроме того, обратитесь к программам/файлам из других портов с переменными, перечисленными выше, без указания явных маршрутов. Например, если ваш порт требует, чтобы макро PAGER являлся полным путем утилиты less, используйте флаг компилятора:

-DPAGER=\"${PREFIX}/bin/less\"
   

-DPAGER=\"${LOCALBASE}/bin/less\"
   

16.1. Введение

Вот список часто встречающихся действий, которые нужно и которые нельзя делать во время процесса портирования. Вы должны проверять ваш порт по этому списку, и вы также можете проверять порты в базе сообщений PR, которые присланы другими людьми. Присылайте любые комментарии о портах, которые вы проверили, так, как это описано в статье о Сообщениях об ошибках и общих замечаниях. Проверка портов в базе сообщений PR позволит нам быстрее коммиттить их и удостовериться, что вы знаете, что делаете.

16.2. Удаление отладочной информации в бинарных файлах

Не удаляйте отладочную информацию из бинарных файлов вручную, если вы это делали. Во всех двоичных файлах отладочная информация должна быть удалена, и макрос INSTALL_PROGRAM будет выполнять установку и удаление отладочной информации одновременно (обратитесь к следующему разделу).

Если вам нужно удалить отладочную информацию из файла, но без использования макроса INSTALL_PROGRAM, то это можно сделать при помощи ${STRIP_CMD}. Обычно это делается внутри цели post-install. К примеру:

post-install:
    ${STRIP_CMD} ${PREFIX}/bin/xdl

Для проверки того, удалена ли отладочная информация из установленного выполнимого файла, выполните команду file(1). Если утилита не выдаст строку not stripped, то файл уже обработан. Кроме того, strip(1) не будет обрабатывать программу, отладочная информация из которой уже удалена; вместо этого утилита просто завершит свою работу.

16.3. Макросы INSTALL_*

Используйте макросы, которые есть в файле bsd.port.mk для обеспечения правильных прав доступа и владения файлов в своих целях *-install.

• INSTALL_PROGRAM - это команда для установки бинарных выполнимых файлов.

• INSTALL_SCRIPT - это команда для установки выполнимых скриптов.

• INSTALL_DATA - это команда для установки совместно используемых файлов данных.

• INSTALL_MAN - это команда для установки страниц Справочника и другой документации (никаких файлов она не сжимает).

В основе работы этих макросов лежит команда install со всеми соответствующими флагами. Смотрите пример их использования ниже.

16.4. WRKDIR

Не пишите ничего в файлы вне каталога WRKDIR. Каталог WRKDIR является единственным местом, которое гарантированно будет доступно для записи во время построения порта (обратитесь к главе о установке портов с CDROM за примером построения портов из дерева, доступного только для чтения). Если вам нужно изменить какой-либо из файлов pkg-*, сделайте это, переопределив переменную, но не перезаписывая их.

16.5. WRKDIRPREFIX

Добейтесь того, чтобы ваш порт принимал во внимание значение переменной WRKDIRPREFIX. Большинство портов об этом не заботятся. В частности, если вы обращаетесь к каталогу WRKDIR другого порта, заметьте, что его правильным местоположением является WRKDIRPREFIXPORTSDIR/subdir/name/work not PORTSDIR/subdir/work или .CURDIR/../../subdir/name/work или что-то подобное.

Кроме того, если вы сами задаете WRKDIR, то должны поставить перед ним знак ${WRKDIRPREFIX}${.CURDIR}.

16.6. Различение операционных систем и версий ОС

Вы можете встретиться с кодом, который требует модификаций или условной компиляции в зависимости от того, с какой версией Unix он работает. Если вам нужно сделать такие изменения в коде для условной компиляции, то вы должны делать изменения как можно более общими, чтобы мы могли перенести код на более старые системы FreeBSD, а также и на другие системы BSD, такие, как 4.4BSD от CSRG, BSD/386, 386BSD, NetBSD, и OpenBSD.

Предпочтительным способом отделения кода для 4.3BSD/Reno (1990) и и более новых версий BSD является использование макроса BSD, определенного в файле <sys/param.h>. Хорошо, если этот файл уже включен; если это не так, то добавьте такой код:

#if (defined(__unix__) || defined(unix)) && !defined(USG)
#include <sys/param.h>
#endif
     

в соответствующем месте файла .c. Мы надеемся, что все системы, в которых определены эти две константы, имеют файл sys/param.h. Если вы обнаружите систему, в которой это не так, мы хотим знать. Пошлите, пожалуйста, письмо на адрес Список рассылки, посвящённый Портам FreeBSD.

Другим способом является использование для этого стиля GNU Autoconf:

#ifdef HAVE_SYS_PARAM_H
#include <sys/param.h>
#endif
     

Не забудьте добавить -DHAVE_SYS_PARAM_H к CFLAGS в файле Makefile при использовании этого метода.

Как только вы включите sys/param.h, то сможете воспользоваться следующим:

#if (defined(BSD) && (BSD >= 199103))
     

для определения того, компилируется ли программа на основе кода Net2 версии 4.3 или более новой версии (например, FreeBSD 1.x, 4.3/Reno, NetBSD 0.9, 386BSD, BSD/386 1.1 и ниже).

Используйте:

#if (defined(BSD) && (BSD >= 199306))
     

для определения того, компилируется ли программа на основе кода 4.4 или более новой (например, FreeBSD 2.x, 4.4, NetBSD 1.0, BSD/386 2.0 и выше).

Значение макроса BSD равно 199506 для кода на основе 4.4BSD-Lite2. Оно задано только для информационной целей. Оно не должно использоваться для различия между версиями FreeBSD, основанными на коде 4.4-Lite и версиями, в которые включены изменения из 4.4-Lite2. Вместо этого нужно использовать макрос __FreeBSD__.

Реже используйте:

• __FreeBSD__ определён во всех версиях FreeBSD. Используйте его, если изменение, вносимое вами, касается только FreeBSD. Проблемы портирования, такие, как использование sys_errlist[] или strerror() являются особенностями систем BSD, а не FreeBSD.

• Во FreeBSD 2.x, значение __FreeBSD__ определено как 2. В более ранних версиях оно равно 1. В более поздних версиях это значение всегда увеличивается в соответствии со старшим номером версии системы.

• Если вам нужно отделить системы FreeBSD 1.x от систем FreeBSD 2.x и более старших, правильным способом, как правило, будет использование макроса BSD, описанное выше. Если это действительно изменение, специфичное для FreeBSD (например, особая опция для динамической библиотеки при использовании ld), то для распознавания систем FreeBSD 2.x и более поздних нормальным будет использование __FreeBSD__ и #if __FreeBSD__ > 1. Если вам нужно более точное определение версий FreeBSD, начиная с 2.0-RELEASE, то вы можете использовать следующее:

  #if __FreeBSD__ >= 2
  #include <osreldate.h>
  #    if __FreeBSD_version >= 199504
       /* 2.0.5+ release specific code here */
  #    endif
  #endif
       
  

Из сотен уже сделанных портов только в одном или двух случаях потребовалось использование __FreeBSD__. Если старые порты использовали этот макрос не по назначению, вовсе не значит, что вам нужно поступать точно также.

16.7. Значения __FreeBSD_version

Ниже для справки приводится перечень значений __FreeBSD_version в виде, который определён в sys/param.h:

16.8. Написание чего-либо после bsd.port.mk

Не пишите ничего после строки .include <bsd.port.mk>. Этой строки можно избежать, включив в где-то в середину вашего файла Makefile файл bsd.port.pre.mk, и файл bsd.port.post.mk в конец.

В файле bsd.port.pre.mk определяются лишь несколько переменных, которые могут быть использованы в тестах из файла Makefile, в файле bsd.port.post.mk заданы остальные.

Вот некоторые важные переменные, определенные в файле bsd.port.pre.mk (это не полный список, для выяснения полного списка прочтите, пожалуйста, сам файл bsd.port.mk).

Вот несколько примеров того, что вы можете написать после bsd.port.pre.mk:

# no need to compile lang/perl5 if perl5 is already in system
.if ${OSVERSION} > 300003
BROKEN= perl is in system
.endif

# only one shlib version number for ELF
.if ${PORTOBJFORMAT} == "elf"
TCL_LIB_FILE=  ${TCL_LIB}.${SHLIB_MAJOR}
.else
TCL_LIB_FILE=  ${TCL_LIB}.${SHLIB_MAJOR}.${SHLIB_MINOR}
.endif

# software already makes link for ELF, but not for a.out
post-install:
.if ${PORTOBJFORMAT} == "aout"
       ${LN} -sf liblinpack.so.1.0 ${PREFIX}/lib/liblinpack.so
.endif

Вы не забываете об использовании табуляции вместо пробелов после BROKEN= и TCL_LIB_FILE=, не так ли? :-).

16.9. Установка дополнительной документации

Если с вашим программным обеспечением поставляется некоторая документация, отличающаяся от стандартных страниц Справочника и файлов info, которая, как вы думаете, будет полезна пользователям, установите ее в каталог PREFIX/share/doc. Это может быть сделано, как и в предыдущем разделе, в цели post-install.

Создайте для вашего порта новый каталог. Имя каталога должно соответствовать тому, что представляет из себя порт. Обычно это означает PORTNAME. Однако, если вы думаете, что пользователь захочет иметь разные версии порта, установленные одновременно, то вы можете использовать полное имя PKGNAME.

Сделайте установку документации зависящей от переменной NOPORTDOCS для того, чтобы пользователи могли выключить это в файле /etc/make.conf, как здесь:

post-install:
.if !defined(NOPORTDOCS)
    ${MKDIR} ${DOCSDIR}
    ${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${DOCSDIR}
 .endif

Вот несколько полезных переменных и то, как они преобразуются по умолчанию при использовании в Makefile:

• DATADIR преобразуется в PREFIX/share/PORTNAME.

• DOCSDIR преобразуется в PREFIX/share/doc/PORTNAME.

• EXAMPLESDIR преобразуется в PREFIX/share/examples/PORTNAME.

Эти переменные экспортируются в PLIST_SUB. Их значения появятся там в виде имён путей относительно PREFIX, если это возможно. То есть share/doc/PORTNAME в списке сборки по умолчанию будет заменен на %%DOCSDIR%%, и так далее. (Дополнительную информацию о подстановке в pkg-plist можно найти здесь.)

Все устанавливаемые файлы с документацией и каталоги должны быть перечислены в файле pkg-plist с префиксом %%PORTDOCS%%, например:

%%PORTDOCS%%%%DOCSDIR%%/AUTHORS
%%PORTDOCS%%%%DOCSDIR%%/CONTACT
%%PORTDOCS%%@dirrm %%DOCSDIR%%

Кроме того, вы можете использовать файл pkg-message для вывода сообщений во время установки. За подробной информацией обратитесь к разделу об использовании pkg-message.

В качестве альтернативы перечислению файлов документации в файле pkg-plist, порт может указать в переменной PORTDOCS список имён файлов и глобальных шаблонов командного процессора для добавления в окончательный список сборки. Имена будут задаваться относительно DOCSDIR. Таким образом, порт, использующий PORTDOCS и нестандартное местоположение документации, должен задавать соответствующим образом и DOCSDIR. Если каталог указан в PORTDOCS или соответствует шаблону для этой переменной, то полное поддерево с входящими в него файлами и каталогами будет регистрироваться в окончательном списке сборки. PORTDOCS не должна задаваться, если определена переменная NOPORTDOCS. Установка документации в PORTDOCS, как это показано выше, остаётся за самим портом. Типичный пример использования PORTDOCS выглядит следующим образом:

.if !defined(NOPORTDOCS)
    PORTDOCS=   *
.endif

16.10. Подкаталоги

Попробуйте поместить все файлы порта в правильных подкаталогах каталога PREFIX. Некоторые порты игнорируют все установки и помещают все в подкаталог с именем порта, что неправильно. Также многие порты помещают все, кроме бинарных файлов, файлов заголовков и страниц Справочника, в подкаталог каталога lib, что не очень хорошо работает с подходом BSD. Многие файлы должны быть перемещены в одно из следующих местоположений: etc (настроечные/конфигурационные файлы), libexec (выполнимые файлы, запускаемые из других программ), sbin (исполнимые файлы для администраторов/менеджеров системы), info (документация в формате info для просмотрщика info) или share (независимые от архитектуры файлы). Обратитесь к hier(7) для прояснения деталей; правила, покрывающие /usr, достаточно хорошо подходят также и к /usr/local. Исключением являются порты, имеющие дело с ``новостями'' USENET. Они могут использовать каталог PREFIX/news для установки своих файлов.

16.11. Очистка пустых каталогов

Заставьте ваш порты очищать за собой при удалении. Обычно это достигается добавлением строк @dirrm для всех каталогов, которые создаются этим портом. Вам нужно удалить подкаталоги до того, как вы сможете удалить родительские каталоги.

 :
lib/X11/oneko/pixmaps/cat.xpm
lib/X11/oneko/sounds/cat.au
 :
@dirrm lib/X11/oneko/pixmaps
@dirrm lib/X11/oneko/sounds
@dirrm lib/X11/oneko
     

Однако иногда @dirrm будет выдавать ошибку, потому что другие порты тоже используют тот же самый подкаталог. Вы можете вызвать команду rmdir из @unexec для удаления без выдачи предупреждений только пустого каталога.

@unexec rmdir %D/share/doc/gimp 2>/dev/null || true

Эта команда не выведет никаких сообщений об ошибках и не вызовет аварийного завершения работы pkg_delete(1), даже если каталог PREFIX/share/doc/gimp не пуст из-за того, что другие порты установили сюда какие-то файлы.

16.12. Идентификаторы UID

Если вашему порту требуется наличие некоторого пользователя в системе, на которую он устанавливается, пусть скрипт pkg-install вызовет команду pw для его автоматического создания. Посмотрите для примера на net/cvsup-mirror.

Если ваш порт должен использовать тот же самый идентификатор пользователя или группы при установке двоичного пакета, который был при компиляции, то вы должны выбрать свободный UID в диапазоне от 50 до 999 и зарегистрировать его ниже. Взгляните для примера на japanese/Wnn6.

Удостоверьтесь, что не используете UID, уже зарезервированный системой или другими портами.

Вот текущий перечень используемых UID между 50 и 999.

bind:*:53:53:Bind Sandbox:/:/sbin/nologin
majordom:*:54:54:Majordomo Pseudo User:/usr/local/majordomo:/nonexistent
cyrus:*:60:60:the cyrus mail server:/nonexistent:/nonexistent
gnats:*:61:1:GNATS database owner:/usr/local/share/gnats/gnats-db:/bin/sh
proxy:*:62:62:Packet Filter pseudo-user:/nonexistent:/nonexistent
uucp:*:66:66:UUCP pseudo-user:/var/spool/uucppublic:/usr/libexec/uucp/uucico
xten:*:67:67:X-10 daemon:/usr/local/xten:/nonexistent
pop:*:68:6:Post Office Owner (popper):/nonexistent:/sbin/nologin
wnn:*:69:7:Wnn:/nonexistent:/nonexistent
pgsql:*:70:70:PostgreSQL pseudo-user:/usr/local/pgsql:/bin/sh
oracle:*:71:71::0:0:Oracle:/usr/local/oracle7:/sbin/nologin
ircd:*:72:72:IRC daemon:/nonexistent:/nonexistent
ircservices:*:73:73:IRC services:/nonexistent:/nonexistent
ifmail:*:75:66:Ifmail user:/nonexistent:/nonexistent
www:*:80:80:World Wide Web Owner:/nonexistent:/sbin/nologin
alias:*:81:81:QMail user:/var/qmail/alias:/nonexistent
qmaild:*:82:81:QMail user:/var/qmail:/nonexistent
qmaill:*:83:81:QMail user:/var/qmail:/nonexistent
qmailp:*:84:81:QMail user:/var/qmail:/nonexistent
qmailq:*:85:82:QMail user:/var/qmail:/nonexistent
qmailr:*:86:82:QMail user:/var/qmail:/nonexistent
qmails:*:87:82:QMail user:/var/qmail:/nonexistent
mysql:*:88:88:MySQL Daemon:/var/db/mysql:/sbin/nologin
vpopmail:*:89:89:VPop Mail User:/usr/local/vpopmail:/nonexistent
firebird:*:90:90:Firebird Database Administrator:/usr/local/firebird:/bin/sh
mailman:*:91:91:Mailman User:/usr/local/mailman:/sbin/nologin
gdm:*:92:92:GDM Sandbox:/:/sbin/nologin
jabber:*:93:93:Jabber Daemon:/nonexistent:/nonexistent
p4admin:*:94:94:Perforce admin:/usr/local/perforce:/sbin/nologin
interch:*:95:95:Interchange user:/usr/local/interchange:/sbin/nologin
squeuer:*:96:96:SQueuer Owner:/nonexistent:/bin/sh
mud:*:97:97:MUD Owner:/usr/local/share/dgd:/bin/sh
msql:*:98:98:mSQL-2 pseudo-user:/var/db/msqldb:/bin/sh
rscsi:*:99:99:Remote SCSI:/usr/local/rscsi:/usr/local/sbin/rscsi
squid:*:100:100:squid caching-proxy pseudo user:/usr/local/squid:/sbin/nologin
quagga:*:101:101:Quagga route daemon pseudo user:/usr/local/etc/quagga:/sbin/nologin
ganglia:*:102:102:Ganglia User:/nonexistent:/sbin/nologin
sgeadmin:*:103:103:Sun Grid Engine Admin:/nonexistent:/sbin/nologin
slimserv:*:104:104:Slim Devices SlimServer pseudo-user:/nonexistent:/sbin/nologin
dnetc:*:105:105:distributed.net client and proxy pseudo-user:/nonexistent:/sbin/nologin
clamav:*:106:106:Clamav Antivirus:/nonexistent:/sbin/nologin
cacti:*:107:107:Cacti Sandbox:/nonexistent:/sbin/nologin
fido:*:111:111:Fido System:/usr/local/fido:/bin/sh
postfix:*:125:125:Postfix Mail System:/var/spool/postfix:/sbin/nologin
rbldns:*:153:153:rbldnsd pseudo-user:/nonexistent:/sbin/nologin
sfs:*:171:171:Self-Certifying File System:/nonexistent:/sbin/nologin
agk:*:172:172:AquaGateKeeper:/nonexistent:/nonexistent
moinmoin:*:192:192:MoinMoin User:/nonexistent:/sbin/nologin
ldap:*:389:389:OpenLDAP Server:/nonexistent:/sbin/nologin
drweb:*:426:426:Dr.Web Mail Scanner:/nonexistent:/sbin/nologin
qtss:*:554:554:Darwin Streaming Server:/nonexistent:/sbin/nologin
ircdru:*:555:555:Russian hybrid IRC server:/nonexistent:/bin/sh
bacula:*:910:910:Bacula Daemon:/var/db/bacula:/sbin/nologin

Вот текущий перечень зарезервированных GID.

bind:*:53:
cyrus:*:60:
proxy:*:62:
authpf:*:63:
uucp:*:66:
dialer:*:68:
network:*:69:
pgsql:*:70:
www:*:80:
qnofiles:*:81:
qmail:*:82:
mailman:*:91:
postfix:*:125:
maildrop:*:126:
rbldns:*:153:
moinmoin:*:192:
qtss:*:554:
ircdru:*:555:

Пожалуйста, при посылке нового (или обновлении старого) порта напишите замечание, что резервируете новый UID или GID в этом диапазоне. Это позволит нам держать список зарезервированных идентификаторов в актуальном состоянии.

16.13. Поступайте разумно

Файл Makefile должен выполнять действия просто и небеспричинно. Если вы можете сделать что-то на несколько строк короче или более читабельно, сделайте это. В качестве примеров можно привести использование конструкций .if утилиты make вместо соответствующей конструкции if командного процессора, ненужность переопределения цели do-extract при возможности переопределения EXTRACT* и использование GNU_CONFIGURE вместо CONFIGURE_ARGS+= --prefix=${PREFIX}.

Если вы обнаружите, что для выполнения чего-то приходится писать много нового кода, то, пожалуйста, просмотрите файл bsd.port.mk на предмет того, не содержит ли он реализацию именно вашей проблемы. Хотя его трудно читать, имеется много проблем, выглядящих сложными, для которых файл bsd.port.mk уже содержит быстрое решение.

16.14. Работа как с CC, так и CXX

Порт должен принимать во внимание как переменную CC, так и CXX. Под этим мы подразумеваем, что порт ни в коем случае не должен устанавливать значения этих переменных, переопределяя имеющиеся значения; вместо этого от должен добавлять те значения, которые нужны, к имеющимся. Это нужно для того, чтобы параметры построения, относящиеся ко всем портам, могут быть заданы глобально.

Если порты не принимают во внимание значения этих переменных, пожалуйста, добавьте строку NO_PACKAGE=ignores either cc or cxx в файл Makefile.

Далее следует пример файла Makefile, использующего как переменную CC, так и CXX. Обратите внимание на использование символов ?=:

CC ?= gcc

CXX ?= g++

Вот пример, в котором не принимаются во внимание ни переменная CC, ни CXX:

CC = gcc

CXX = g++

Обе переменные CC и CFLAGS могут быть определены в системах FreeBSD в файле /etc/make.conf. В первом примере задаётся значение, если оно ранее не было определено в /etc/make.conf, что сохраняет любые определения, данные на уровне системы в целом. Второй пример переопределяет всё, что было задано ранее.

16.15. Использование CFLAGS

Порт должен принимать во внимание переменную CFLAGS. Под этим мы подразумеваем, что порт ни в коем случае не должен устанавливать значения этих переменных, переопределяя имеющиеся значения; вместо этого от должен добавлять те значения, которые нужны, к имеющимся. Это нужно для того, чтобы параметры построения, относящиеся ко всем портам, могут быть заданы глобально.

Если он этого не делает, то, пожалуйста, добавьте в файл Makefile строчку NO_PACKAGE=ignores cflags.

Пример файла Makefile, в котором принимается во внимание переменная CFLAGS, приводится далее. Отметьте употребление символов +=:

CFLAGS += -Wall -Werror
     

А вот пример, в котором не учитывается значение переменной CFLAGS:

CFLAGS = -Wall -Werror
     

В системе FreeBSD переменная CFLAGS определена в файле /etc/make.conf. В первом примере к переменной CFLAGS добавляются дополнительные флаги, при этом сохраняются все определения, данные ранее на уровне системы. Во втором примере всё, что было задано ранее, игнорируется.

16.16. Конфигурационные файлы

Если для работы порта требуются наличие некоторых конфигурационных файлов в каталоге PREFIX/etc, не просто установите их и перечислите в файле pkg-plist. Это приведёт к тому, что по команде pkg_delete(1) или при новой установке файлы, тщательно отредактированные и настроенные пользователем, будут уничтожены.

Вместо этого установите файлы с примерами с неким расширением (filename.sample подойдет) и выведите сообщение, указывающее на то, чтобы пользователь скопировал и отредактировал файл перед тем, как работать с программным обеспечением.

16.17. Пожелания

Посылайте подходящие изменения/патчи авторам/сопровождающему для включения в следующий релиз. Это только сделает вашу работу гораздо легче при выходе следующего релиза.

16.18. README.html

Не включайте сюда файл README.html. Этот файл не является частью дерева cvs, и он генерируется при помощи команды make readme.

16.19. Пометка порта как BROKEN, FORBIDDEN или как-то ещё

Рано или поздно, наступает момент, когда в некотором порте появляется уязвимость в информационной безопасности, либо он перестаёт работать и необходимы многие часы на тщательное исправление этого положения, либо он вообще устаревает, но по той или иной причине должен оставаться в дереве (и должен быть исправлен, правильно?). Для пометки порта как неработоспособного имеются три make-переменные, которые могут быть использованы в файле Makefile порта. Значение следующих make-переменных будут являться причинами, по которым порт помечен как неработоспособный, и выдаются пользователям. Пожалуйста, используйте корректные make-переменные, так как каждая переменная построения имеет абсолютно различный смысл как для пользователей, так и для автоматизированных систем, которые обрабатывают файлы Makefile.

• BROKEN предназначена для портов, которые не работают и не должны устанавливаться пользователями. Это предотвратит пользователей от установки порта.

• TRYBROKEN используется для портов, если вы пожелаете попытаться построить порт, помеченный, как BROKEN. Порты, помеченные, как TRYBROKEN также будут строиться Кластером Pointyhat.

• FORBIDDEN используется для портов, которые содержат уязвимости в информационной безопасности или являются потенциально вредными в плане обеспечения информационной безопасности системы FreeBSD при установке данного порта (например: заведомо небезопасная программа или программа, которая предоставляет легко взламываемые сервисы). Порты должны помечаться как FORBIDDEN, как только в конкретном программном обеспечении обнаружилась уязвимость, но обновление выпущено не было. В идеальном случае порты должны обновляться максимально быстро после обнаружения уязвимости, чтобы уменьшить число уязвимых хостов FreeBSD (нам нравится иметь репутацию безопасной системы), однако иногда случается значительный временной разрыв между обнаружением уязвимости и выходом обновлённого релиза уязвимого программного обеспечения. Не помечайте порт как FORBIDDEN, если причина не вызвана соображениями информационной безопасности.

• IGNORE предназначена для портов, которые по той или иной причине не должны строиться. Пользователи и кластер Pointyhat не будут, ни при каких условиях, строить порты, помеченные как IGNORE. Если вы сомневаетесь, используйте IGNORE, если хотите избежать построения порта.

Имейте в виду, что эти переменные используются как последнее средство при невозможности обновить порт. Постоянно неработоспособные порты должны полностью удаляться из дерева.

16.20. Необходимые предосторожности

Иногда бывает необходимо обходить ошибки в программном обеспечении, которым комплектовались предыдущие версии FreeBSD.

• Некоторые версии make(1) (по крайней мере в версиях 4.8 и 5.0) неправильно отрабатывали сравнение на основе OSVERSION. Это часто приводило к ошибкам при выполнении команды make describe (и, в свою очередь, в целом при выполнении make index для портов). Эта ситуация обходится окружением условной операции сравнения пробелами, например:

  if ( ${OSVERSION} > 500023 )
  

  Учтите, что при тестовой установке порта на 4.9 или 5.2 эта проблемы не обнаруживается.
  
  

16.21. Разное

Файлы pkg-descr и pkg-plist должны проверяться дважды. Если вы пересматриваете порт и думаете, что его можно описать иначе, сделайте это.

Пожалуйста, не создавайте дополнительных копий лицензии GNU General Public License в нашей системе.

Будьте внимательны с юридическими вопросами! Не делайте из нас нелегальных распространителей ПО!

16.22. Если вы испытываете затруднения...

Посмотрите существующие примеры и файл bsd.port.mk перед тем, как задавать нам вопросы! ;-)

Задавайте нам вопросы, если у вас появились проблемы! Не бейтесь головой об стену! :-)

19.1. FreshPorts

Самым простым способом отслеживать уже произошедшие обновления является подписка на FreshPorts. Для мониторинга вы можете выбрать несколько портов. Мейнтейнерам настоятельно рекомендуется подписаться здесь, потому что они будут получать уведомления не только о собственных изменениях, но и об изменениях, сделанных любым другим коммиттером FreeBSD. (Это часто необходимо для синхронизации с изменениями на более низком технологическом уровне--хотя более корректным было бы получение предупреждений от тех, кто вносит подобные изменения, иногда этот этап пропускается или он просто непрактичен. Кроме того, в некоторых случаях изменения по своей природе весьма незначительны. Мы полагаем, что любой разработчик в таких ситуациях будет руководствоваться здравым смыслом).

Если вы хотите использовать FreshPorts, то вам нужна только учётная запись. Если регистрационный адрес вашей электронной почты будет иметь вид @FreeBSD.org, то справа на Web-страницах вы увидите дополнительную ссылку. Для тех из вас, кто уже получил учётную запись FreshPorts, но не использовал собственный адрес электронной почты @FreeBSD.org, достаточно сменить адрес на @FreeBSD.org, подписаться, а затем сменить его обратно.

Во FreshPorts имеется также функция проверки правильности, которая автоматически проверяет каждое изменение, внесённое в дерево портов FreeBSD. Если вы подпишетесь на эту услугу, то будете оповещаться обо всех ошибках, обнаруженных FreshPorts при проверке внесённых вами изменений.

19.2. Web-интерфейс к хранилищу исходных текстов

Файлы в хранилище исходных текстов можно просматривать при помощи Web-интерфейса. Изменения, которые касаются в целом всей системы портов, теперь документируются в файле CHANGES. Изменения, касающиеся отдельных портов, отражаются теперь в файле UPDATING. Однако однозначный ответ на любой вопрос можно найти, только прочитав исходных код bsd.port.mk и связанных с ним файлов.

19.3. Список рассылки FreeBSD, посвящённый портам

Если вы поддерживаете порты, то должны следить за Список рассылки, посвящённый Портам FreeBSD. О важных изменениях, отражающихся на работе портов, будет сообщаться здесь, а затем они переносятся в CHANGES.

19.4. Кластер построения портов FreeBSD

Одной из наименее известных сильных сторон FreeBSD является тот факт, что для непрерывного построения Коллекции Портов для каждого из основных релизов ОС для каждой архитектуры уровня поддержки Tier-1 выделен целый кластер машин. Вы можете увидеть результаты этих построений в протоколах построения пакетов и обнаруженных ошибок.

19.5. Проверка дистрибутивных файлов портов FreeBSD

Кластер построения выделен для выполнения самого последнего релиза каждого из портов, дистрибутивный файл которых уже был сгружен. Однако из-за постоянных изменений в Internet, дистрибутивные файлы быстро исчезают. Средство инспектирования дистрибутивных файлов FreeBSD пытается опросить каждый из сайтов, доступный для сгрузки каждого из портов для определения того, доступны ли ещё дистрибутивные файлы. Мейнтейнеры должны периодически просматривать этот протокол, и не только для ускорения процесса построения пользователем, но и для избежания траты пропускной способности сайтов, на которых все эти дистрибутивные файлы размещаются на добровольной основе.

19.6. Система мониторинга портов FreeBSD

Другим полезным ресурсом является Система мониторинга портов FreeBSD (известная также как portsmon). Система представляет собой базу данных, обрабатывающую информацию из нескольких источников и позволяющую просматривать их при помощи Web-интерфейса. На данный момент задействованы база сообщений об ошибках (PR), протоколы ошибок кластера построения и отдельные файлы из коллекции портов. В будущем в этот список будет добавлена система проверки дистрибутивных файлов и другие ресурсы.

Для начала вы можете просмотреть всю информацию о некотором порте при помощи средства Просмотра отдельных портов.