3.4. Вопросы повышенной сложности

3.4.2.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.4.2.2. Создание информационных файлов

Имеется три информационных файла, которые требуются для любого порта, вне зависимости от того, является ли он пакаджем или нет. Это COMMENT, DESCR, и PLIST, а располагаются они в подкаталоге pkg.

    A cat chasing a mouse all over the screen

    	

    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

    	

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.4.3.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, теперь давайте пройдемся через рекомендуемые для создания настоящего порта шаги.

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

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

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

Если вы не можете найти доступного и надежного места для помещения дистрибутивного файла (если вы являетесь коммиттером. можете просто поместить его в ваш каталог public_html/ на машине freefall), мы можем ``держать'' его, поместив в ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/LOCAL_PORTS/ на крайний случай. Пожалуйста, отразите это местоположение как MASTER_SITE_LOCAL. Пошлите письмо в адрес Список рассылки посвященный Портам FreeBSD <freebsd-ports@FreeBSD.org>, если вы не уверены, как следует поступить.

Если дистрибутивные файлы вашего порта постоянно меняются по непонятным причинам, остается поместить дистрибутив на вашу домашнюю веб-страницу и указать ее первой в списке MASTER_SITES. Это позволит избежать получения ошибок ``checksum mismatch'' у пользователей, а также уменьшит нагрузку на людей, сопровождающих наш ftp-сервер. Также, если у порта имеется только один основной сервер, то рекомендуется поместить архивную копию на свой сайт и указать его в списке MASTER_SITES вторым.

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

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

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

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

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

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

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

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

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

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

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

3.4.4.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 для переопределения действий по умолчанию, хотя к этому нужно будет прибегать в очень редких случаях, если вообще придётся.

3.4.4.2. PORTNAME и PORTVERSION

В переменной PORTNAME вы должны указать основную часть имени вашего порта, а в переменной PORTVERSION - номер версии.

3.4.4.3. Переменные PKGNAMEPREFIX и PKGNAMESUFFIX

Две необязательные переменные, PKGNAMEPREFIX и PKGNAMESUFFIX, объядиняются со значениями PORTNAME и PORTVERSION для формирования PKGNAME в форме ${PKGNAMEPREFIX}${PORTNAME}${PKGNAMESUFFIX}-${PORTVERSION}. Добейтесь того, чтобы это соответствовало нашим рекомендациям по правильному выбору названий для пакаджей. В частности, в переменной PORTVERSION не разрешается использование дефиса (-). Кроме того, если в имени пакаджа присутствует часть language- или compiled.specifics, то используйте переменные PKGNAMEPREFIX и PKGNAMESUFFIX, соответственно. Не делайте их частью значения переменной PORTNAME.

3.4.4.4. DISTNAME

В переменной DISTNAME указывается имя порта так, как назвали его создатели программного обеспечения. Значение DISTNAME по умолчанию совпадает с ${PORTNAME}-${PORTVERSION}, так что переопределите её значение в случае необходимости. DISTNAME используется только в двух местах. Во-первых, список дистрибутивных файлов (DISTFILES) по умолчанию состоит из ${DISTNAME}${EXTRACT_SUFX}. И во-вторых, предполагается, что дистрибутивный файл будет распакован в подкаталог с именем WRKSRC, значение которого по умолчанию есть не что иное, как work/${DISTNAME}.

Заметьте, что значения переменных PKGNAMEPREFIX и PKGNAMESUFFIX не влияют на значение DISTNAME.

3.4.4.5. CATEGORIES

В процессе создания пакаджа он помещается в каталог /usr/ports/packages/All, а в одном или более подкаталогов из /usr/ports/packages создаются на него ссылки. Имена этих подкаталогов определяются переменной CATEGORIES. Такая схема нужна для облегчения жизни пользователя, когда он сталкивается с массой пакаджей на ftp-сервере или компакт-диске. Пожалуйста, посмотрите на список существующих категорий и выберите те из них, которые более всего подходят к вашему порту.

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

Если ваш порт действительно относится к чему-то, что абсолютно не имеет отношения ни к одной из существующих категорий, вы можете даже создать новую категорию. В этом случае, пожалуйста, пошлите письмо с вашим предложением на адрес Список рассылки посвященный Портам FreeBSD <freebsd-ports@FreeBSD.org>.

3.4.4.6. MASTER_SITES

Содержит часть с каталогом ftp/http-URL, которая указывает на оригинальный архив на сервере MASTER_SITES. Не забудьте лидирующий слэш (/)!

Макрос команды make будет пытаться воспользоваться этой переменной для получения дистрибутивного файла с помощью программы FETCH, если он не будет найден в системе.

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

Если оригинальный архив находится на одном из следующих популярных серверов: X-contrib, GNU, Perl CPAN, TeX CTAN, или Linux Sunsite, указывайте эти сайты в простой форме при помощи MASTER_SITE_XCONTRIB, MASTER_SITE_GNU, MASTER_SITE_PERL_CPAN, MASTER_SITE_TEX_CTAN, и MASTER_SITE_SUNSITE. В переменной MASTER_SITE_SUBDIR просто задайте путь к архиву. Вот пример:

    MASTER_SITES=	      ${MASTER_SITE_XCONTRIB}

    MASTER_SITE_SUBDIR=   applications

          

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

3.4.4.7. PATCHFILES

Если вашему порту требуются некоторых дополнительные патчи, которые доступны по ftp или http, задайте имена этих файлов в переменной PATCHFILES, а в переменной PATCH_SITES укажите URL того каталога, в котором они содержатся (формат такой же, как для MASTER_SITES).

Если патч не относится к самому верху дерева исходных текстов (то есть WRKSRC), потому что он содержит некоторые дополнительные пути, установите соответственно значение переменной PATCH_DIST_STRIP. В частности, если все имена путей в патче имеют дополнительный путь foozolix-1.0/ перед именем файла, то задайте PATCH_DIST_STRIP=-p1.

Не волнуйтесь, если патчи упакованы, они будут распакованы автоматически, если имена файлов оканчиваются на .gz или .Z.

Если патч распространяется вместе с какими-то другими файлами, такими, как документация, в виде tar-архива gzip, вы не можете просто использовать PATCHFILES. Если это ваш случай, добавьте имя и местоположение архива с патчем к DISTFILES и MASTER_SITES. Затем из цели pre-patch примените патч либо через запуск оттуда команды patch, либо скопировав файл с патчем в каталог PATCHDIR и назвав его patch-xx.

3.4.4.8. MAINTAINER

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

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

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

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

     LIB_DEPENDS=

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

    RUN_DEPENDS=   ${PREFIX}/etc/innd:${PORTSDIR}/news/inn \

    	       wish8.0:${PORTSDIR}/x11-toolkits/tk80

    	

     BUILD_DEPENDS=

    	  unzip:${PORTSDIR}/archivers/unzip

     FETCH_DEPENDS=

    	  ncftp2:${PORTSDIR}/net/ncftp2

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

3.4.4.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=yes. Это подразумевает 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.

3.4.5.1. ldconfig

Если ваш порт устанавливает совместно используемую библиотеку, добавьте цель post-install в ваш Makefile, и запускайте там ${LDCONFIG} -m в каталоге, где установлена новая библиотека (обычно PREFIX/lib) для ее регистрации в кэше совместно используемых библиотек.

Добавьте пару соответствующих команд @exec /sbin/ldconfig -m и @unexec /sbin/ldconfig -R в файл pkg/PLIST, чтобы пользователь, устанавливающий пакадж, мог использовать динамическую библиотеку сразу же, а удаление пакаджа не приводило к тому, что система полагала, что библиотека все еще имеется в наличии. Эти строчки должны следовать сразу же за строчкой с совместно используемой библиотекой, как здесь:

    lib/libtvl80.so.1

    @exec /sbin/ldconfig -m %D/lib

    @unexec /sbin/ldconfig -R

          

Никогда не позволяйте себе добавлять строчку, которая говорит ldconfig без аргументов в вашем файле Makefile или pkg/PLIST. Это приведет к сбросу кэша библиотек к содержимому только /usr/lib, и возникновению кошмарных проблем с машиной пользователя ("Помогите, после установки этого порта xinit больше не запускается!"). Всякий, кто посмеет это сделать, будет пристрелен на месте и острым ножичком разрезан на 65,536 кусочков, его печень будет отдана на съедение воронам, а сам он будет приговорен к бесконечной смерти в глубочайших безднах ада (не обязательно в указанной последовательности...)

3.4.9.1. REQUIRES_MOTIF

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

3.4.9.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.

3.4.12.1. MESSAGE

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

3.4.12.2. INSTALL

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

3.4.12.3. REQ

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

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

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

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

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

    OCTAVE_VERSION= 2.0.13

    PLIST_SUB=	OCTAVE_VERSION=${OCTAVE_VERSION}

    	

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

3.4.12.5. Изменение имен файлов в подкаталоге pkg

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

Вот список имен переменных и их значений по умолчанию.

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

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

Удаляйте отладочную информацию из бинарных файлов. Если в исходных текстах файлы уже усекается, это прекрасно; в противном случае вы должны добавить в цель post-install правило для выполнения этой операции самим. Вот пример:

    post-install:

    	strip ${PREFIX}/bin/xdl

          

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

3.4.15.2. Макросы INSTALL_*

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

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

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

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

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

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

3.4.15.3. WRKDIR

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

3.4.15.4. WRKDIRPREFIX

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

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

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

Вы можете встретиться с кодом, который требует модификаций или условной компиляции в зависимости от того, с какой версией UNIX он работает. Если вам нудно сделать такие изменения в коде для условной компиляции, то вы должны делать изменения как можно более общими, чтобы мы могли перенести код на системы FreeBSD версий 1.x, а также и на другие системы 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 <freebsd-ports@FreeBSD.org>.

Другим способом является использование для этого стиля 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 или 3.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_version
  2.0-RELEASE	119411
  2.1-CURRENT	199501, 199503
  2.0.5-RELEASE	199504
  2.2-CURRENT до выхода 2.1	199508
  2.1.0-RELEASE	199511
  2.2-CURRENT до выхода 2.1.5	199512
  2.1.5-RELEASE	199607
  2.2-CURRENT до выхода 2.1.6	199608
  2.1.6-RELEASE	199612
  2.1.7-RELEASE	199612
  2.2-RELEASE	220000
  2.2.1-RELEASE	220000 (без изменений)
  2.2-STABLE после выхода 2.2.1-RELEASE	220000 (без изменений)
  2.2-STABLE после включения texinfo-3.9	221001
  2.2-STABLE после включения top	221002
  2.2.2-RELEASE	222000
  2.2-STABLE после выхода 2.2.2-RELEASE	222001
  2.2.5-RELEASE	225000
  2.2-STABLE после выхода 2.2.5-RELEASE	225001
  2.2-STABLE после появления ldconfig -R	225002
  2.2.6-RELEASE	226000
  2.2.7-RELEASE	227000
  2.2-STABLE после выхода 2.2.7-RELEASE	227001
  2.2-STABLE после изменения в semctl(2)	227002
  2.2.8-RELEASE	228000
  2.2-STABLE после выхода 2.2.8-RELEASE	228001
  3.0-CURRENT до изменения в mount(2)	300000
  3.0-CURRENT после изменения в mount(2)	300001
  3.0-CURRENT после изменения в semctl(2)	300002
  3.0-CURRENT после изменений в аргументах ioctl	300003
  3.0-CURRENT после перехода на формат ELF	300004
  3.0-RELEASE	300005
  3.0-CURRENT после выхода 3.0-RELEASE	300006
  3.0-STABLE после разбиения на ветки 3/4	300007
  3.1-RELEASE	310000
  3.1-STABLE после выхода 3.1-RELEASE	310001
  3.1-STABLE после изменения в порядке следования конструкторов/деструкторов в C++	310002
  3.2-RELEASE	320000
  3.2-STABLE	320001
  3.2-STABLE после несовместимых изменений в IPFW и сокетах	320002
  3.3-RELEASE	330000
  3.3-STABLE	330001
  3.3-STABLE после добавления mkstemps() в libc	330002
  3.4-RELEASE	340000
  3.4-STABLE	340001
  4.0-CURRENT после появления ветки 3.4	400000
  4.0-CURRENT после изменения в работе динамического компоновщика	400001
  4.0-CURRENT после изменения в порядке следования конструкторов/деструкторов в C++	400002
  4.0-CURRENT после появления функции dladdr(3)	400003
  4.0-CURRENT после исправления ошибки в работе функции __deregister_frame_info динамического компоновщика (а также 4.0-CURRENT после интеграции EGCS 1.1.2)	400004
  4.0-CURRENT после изменения интерфейса функции suser(9) (а также 4.0-CURRENT после появления newbus)	400005
  4.0-CURRENT после изменения в регистрации cdevsw	400006
  4.0-CURRENT после добавления so_cred в проверки на уровне сокетов	400007
  4.0-CURRENT после добавления обработчика системного вызова poll в libc_r	400008
  4.0-CURRENT после перехода в ядре с типа dev_t на указатель struct specinfo	400009
  4.0-CURRENT после исправления дыры в безопасности jail(2)	400010
  4.0-CURRENT после изменения в типе данных sigset_t	400011
  4.0-CURRENT после перехода на компилятор GCC 2.95.2	400012
  4.0-CURRENT после появления добавляемых обработчиков ioctl режима linux	400013
  4.0-CURRENT после заимствования OpenSSL	400014
  4.0-CURRENT после изменения в C++ ABI компилятора GCC 2.95.2 по умолчанию с -fvtable-thunks на -fno-vtable-thunks	400015
  4.0-CURRENT после заимствования OpenSSH	400016
  4.0-RELEASE	400017
  4.0-STABLE после появления 4.0-RELEASE	400018
  5.0-CURRENT	500000
  5.0-CURRENT после добавления дополнительных полей в заголовке ELF и изменения метода пометки принадлежности к определённой системе для выполнимых файлов в формате ELF.	500001
  5.0-CURRENT после изменений в метаданных kld.	500002

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

3.4.15.6. Написание чего-либо после 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

          

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

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

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

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

    post-install:

    .if !defined(NOPORTDOCS)

    	${MKDIR}${PREFIX}/share/doc/xv

    	${INSTALL_MAN} ${WRKSRC}/docs/xvdocs.ps ${PREFIX}/share/doc/xv

    .endif

          

Не забудьте включить их также в файл pkg/PLIST! (Не беспокойтесь здесь о NOPORTDOCS; на данный момент в пакаджах нет способа прочитать значения переменных из /etc/make.conf.)

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

3.4.15.8. DIST_SUBDIR

Не позволяйте вашему порту засорять /usr/ports/distfiles. Если вашему порту требуется сгрузить много файлов, или он содержит имя файла, могущее вызвать конфликты с другими портами (например, Makefile), то укажите в переменной DIST_SUBDIR имя порта (должны подойти ${PORTNAME} или ${PKGNAMEPREFIX}${PORTNAME}). Это изменит значение переменной DISTDIR со значения по умолчанию /usr/ports/distfiles к значению /usr/ports/distfiles/DIST_SUBDIR, и в результате все, что требуется для порта, будет помещено в этот подкаталог.

Он заглянет также в подкаталог с тем же именем на основном резервном сервере ftp.FreeBSD.org. (Явное задание переменной DISTDIR в вашем файле Makefile этого не сделает, так что, пожалуйста, воспользуйтесь DIST_SUBDIR.)

3.4.15.9. Информация о пакадже

Поместите информацию о пакадже, то есть COMMENT, DESCR, и PLIST, в каталог pkg.

3.4.15.10. Строки RCS

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

3.4.15.11. Рекурсивные файлы diff

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

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

3.4.15.12. PREFIX

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

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

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

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

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

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

    	

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

    	

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

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

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

Заставьте ваш порты очищать за собой при удалении. Обычно это достигается добавлением строк @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, даже если каталог PREFIX/share/doc/gimp не пуст из-за того, что другие порты установили сюда какие-то файлы.

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

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

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

Проверьте, что вы не используете UID, уже используемый системой или другими портами. Вот текущий список UID между 50 и 99.

    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

    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:/nonexistent

    wnn:*:69:7:Wnn:/nonexistent:/nonexistent

    ifmail:*:70:66:Ifmail user:/nonexistent:/nonexistent

    pgsql:*:70:70:PostgreSQL pseudo-user:/usr/local/pgsql:/bin/sh

    ircd:*:72:72:IRCd hybrid:/nonexistent:/nonexistent

    alias:*:81:81:QMail user:/var/qmail/alias:/nonexistent

    qmaill:*:83:81:QMail user:/var/qmail:/nonexistent

    qmaild:*:82:81:QMail user:/var/qmail:/nonexistent

    qmailq:*:85:82:QMail user:/var/qmail:/nonexistent

    qmails:*:87:82:QMail user:/var/qmail:/nonexistent

    qmailp:*:84:81:QMail user:/var/qmail:/nonexistent

    qmailr:*:86:82:QMail user:/var/qmail:/nonexistent

    msql:*:87:87:mSQL-2 pseudo-user:/var/db/msqldb:/bin/sh

    mysql:*:88:88:MySQL Daemon:/var/db/mysql:/sbin/nologin

          

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

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

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

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

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

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

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

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

3.4.15.19. Утилита portlint

Проверяйте вашу работу с помощью утилиты portlint перед тем, как послать ее нам или выполнить коммитт.

3.4.15.20. Пожелания

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

3.4.15.21. Разное

Файлы pkg/DESCR, pkg/COMMENT, и pkg/PLIST вы должны проверять дважды. Если вы просматриваете порт и думаете, что его можно переформулировать иначе, сделайте это.

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

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

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

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

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

3.4.19.1. Текущий список категорий

Во-первых, это текущий список категорий. Те, которые отмечены звездочкой (*), являются виртуальными категориями--они не имеют собственного подкаталога в дереве портов.

3.4.19.2. Выбор правильной категории

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

• Сначала всегда идут категории, специфичные для языков. Например, если ваш порт устанавливает японские шрифты для X11, то строчка CATEGORIES должна иметь вид japanese x11-fonts.

• Более конкретные категории предпочтительней перед точных. В частности, редактор HTML должен быть описан как www editors, а не наоброт. Кроме того, вам не нужно указывать категорию net, если порт относится к любой из категорий irc, mail, mbone, news, security или www.

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

• Режимы для редактора Emacs должны помещаться в ту же категорию, что и приложение, которое поддерживается этим режимом, а не в editors. Например, режим Emacs для редактирования исходного кода некоторого языка программирования должен быть помещен в категорию lang.

• Если ваш порт решительным образом не подпадает ни под какую категорию, поместите его в misc.

Если вы не уверены в правильности выбора категории, пожалуйста, отметьте это в вашей посылке по send-pr, чтобы мы могли обсудить это до того, как включить порт в Коллекцию. Если вы являетесь коммиттером, пошлите замечание на адрес Список рассылки посвященный Портам FreeBSD <freebsd-ports@FreeBSD.org>, чтобы мы могли обсудить это--зачастую новые порты помещаются не в ту категорию только для того, чтобы их оттуда сразу же удалили.