12. FAQ по работе с портами

Для начала прочитайте раздел, посвященный репозиторному копированию.

Самым простым будет использовать скрипт addport на машине freefall. Он добавит порт из указанного вами каталоге, определив нужную категорию из файла Makefile, добавит строку в файл CVSROOT/modules и в файл Makefile для нужной категории. Скрипт был написан Michael Haro <[email protected]> и Will Andrews <[email protected]>; вопросы и исправления по поводу addport следует отправлять Уиллу, как текущему мейнтейнеру.

Проверьте его. Желательно убедиться в том, что порт и соответствующий пакет корректно собираются. Рекомендуемая последовательность действий такова:

# make install
# make package
# make deinstall
# pkg_add имя собранного пакета
# make deinstall
# make reinstall
# make package
	   

Более подробные инструкции можно найти в Руководстве FreeBSD по созданию портов.

Пользуйтесь portlint(1) для проверки корректности порта. Не обязательно добиваться полного отсутствия предупреждений, но по крайней мере исправьте простейшие из них.

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

Закройте PR, если новый порт пришел в виде PR. Для этого воспользуйтесь командой edit-pr PR# на машине freefall и измените значение в строке state с open на closed. Затем опишите причину смены статуса, и на этом работа закончена.

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

• Убедитесь, что другие порты не зависят от удаляемого:

  • Имя пакета (PKGNAME) должно встречаться в свежем файле INDEX ровно один раз.

  • В файлах Makefile* других портов не должно встречаться ни одной ссылки на каталог удаляемого порта или имя его пакета (PKGNAME).

• Удалите порт:

  1. Удалите файлы порта командой cvs remove.

  2. Удалите строку SUBDIR для удаляемого порта из файла Makefile категории.

  3. Удалите запись для порта из файла модулей CVSROOT/modules.

  4. Добавьте соответствующую строку в файл ports/MOVED.

  5. Если порт упоминается в файле ports/LEGAL, удалите его оттуда.

Вы можете воспользоваться скриптом rmport из каталога ports/Tools/scripts. Этот скрипт написал Vasil Dimov <[email protected]>, и он же его поддерживает, так что вопросы, исправления и замечания по поводу rmport следует посылать непосредственно ему.

При необходимости добавления порта, имеющего отношение к другому, уже находящемуся в репозитории в другом каталоге, необходимо произвести репозиторное копирование. В данном случае имеющий отношение означает другую версию или небольшую модификацию. Примерами могут служить различные версии print/ghostscript* и английская и локализованные версии x11-wm/windowmaker*.

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

Если нет истории, которую стоило бы сохранять. Для порта, добавленного в неправильную категорию и сразу же перемещенного, будет вполне достаточно выполнить команды cvs remove для старого варианта и addport для нового.

Создайте в GNATS PR, описав причины репозиторного копирования. Поменяйте ответственного на portmgr и установите статус (state) в состояние repocopy. Если ваш запрос будет одобрен группой Группа Менеджеров Дерева Портов FreeBSD <[email protected]>, он будет переадресован на pcvs. Группа Менеджеров Дерева Портов FreeBSD <[email protected]> может произвести копирование каталогов самостоятельно; в противном случае группа Администраторы Репозитория Портов<[email protected]> произведет собственно копирование и вернет вам ваш PR. После этого, вам необходимо проделать следующее:

• После репозиторного копирования порта:

  1. Обновите новый вариант порта до новой версии. Не забудьте изменить строку LATEST_LINK, чтобы не получить двух портов с одним именем. В некоторых исключительных случаях может быть необходимо изменить переменную PORTNAME вместо LATEST_LINK, но это должно быть сделано только тогда когда это действительно нужно. Например, при использовании существующего порта в качестве основы для весьма похожей программы с другим именем или при обновлении порта до новой основной версии программы, при котором изменяется имя самого дистрибутива, как в случае перехода с textproc/libxml на textproc/libxml2. В большинстве случаев изменение LATEST_LINK должно быть достаточно.

  2. Добавьте новый каталог в список SUBDIR в родительском файле Makefile. Для проверки вы можете воспользоваться командой make checksubdirs.

  3. Если порт менял категорию, измените строку CATEGORIES в файле Makefile.

  4. Добавьте строку для нового модуля в CVSROOT/modules.

  5. Добавьте строку в файл ports/MOVED, в случае если вы удалили первоначальный порт.

• При удалении порта:

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

  2. Удалите старый порт, запись SUBDIR и строку, описывающую модуль.

  3. Добавьте строку в файл ports/MOVED.

• После репозиторного перемещения (операции ''переименования'', когда после копирования старый вариант удаляется):

  1. Используйте процедуры из предыдущих двух пунктов для активации нового порта и удаления старого.

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

За дополнительной информацией по поводу правил поведения во время заморозки обращайтесь к документу Задачи контроля качества для Группы управления портами.

Обычно неделю или две.

Во время заморозки вы не можете производить какие-либо коммиты в дерево портов без прямого разрешения группы порт-менеджеров. ''Прямое разрешение'' здесь означает, что вы послали свой патч группе порт-менеджеров и получили ответ ''Вперед, производите коммит''.

В период заморозки не все изменения могут быть внесены в дерево. За подробностями обращайтесь к документу Задачи контроля качества для Группы управления портами.

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

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

Разумеется, после начала периода заморозки в Список рассылки коммиттеров FreeBSD будет отправлено еще одно предупреждение.

Завершение периода заморозки анонсируется группой порт-менеджеров посылкой письма в Список рассылки, посвящённый Портам FreeBSD и Список рассылки коммиттеров FreeBSD через несколько часов после релиза. Отметим, что факт выпуска релиза не означает автоматического завершения заморозки. Нам потребуется убедиться, что в последние минуты не произошло ничего непредвиденного, что заставило бы перевыпускать релиз.

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

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

Обратитесь к разделу Proposing a New Category Руководства по созданию портов. После передачи PR группе Группа Менеджеров Дерева Портов FreeBSD <[email protected]> решение о создании категории остается за ней. В случае утверждения новой категории кто-либо из Группа Менеджеров Дерева Портов FreeBSD <[email protected]> делает следующее:

Процедура является надстройкой над уже описанной процедурой репозиторного копирования отдельного порта.

Специально обновлять веб-страницу портов при добавлении новой категории не нужно: изменение файла www/en/ports/categories будет учтено при ежедневной перестройке списка портов (INDEX) автоматически.

В первую очередь проверьте свой порт по адресу http://pointyhat.FreeBSD.org/errorlogs/. Там вы найдете журналы сборки пакетов на всех поддерживаемых архитектурах для большинства последних ветвей разработки.

Впрочем, отсутствие вашего порта среди журналов с ошибками еще не значит, что он успешно собирается (например, может не собираться один из зависимых портов). Необходимую информацию вы можете найти на машине pointyhat в каталогах /a/portbuild/<arch>/<major_version>. Каждая пара архитектуры и базовой версии содержит следующие подкаталоги:

errors        журналы ошибок последней сборки версии <major_version> на платформе <arch>
logs          все журналы последней сборки версии <major_version> на платформе <arch>
packages      свежесобранные пакеты для версии <major_version> на платформе <arch>
bak/errors    журналы ошибок последней полной сборки версии <major_version> на платформе <arch>
bak/logs      все журналы последней полной сборки версии <major_version> на платформе <arch>
bak/packages  пакеты последней полной сборки версии <major_version> на платформе <arch>

Общее правило: пакет, присутствующий в каталоге packages или каталоге logs, и при этом отсутствующий в errors, собрался успешно. (Именно каталоги errors вы видите на веб-сервере pointyhat).

Нет. INDEX больше не хранится в CVS репозитории. Данный файл может быть сгенерирован с помощью команды make index или уже сгенерированная версия может быть загружена с помощью make fetchindex.

Любой файл в на верхнем уровне ports/, а также все файлы в каталогах, имена которых начинаются с прописной буквы (например, Mk/, Tools/ и т.п.). В частности, упаси вас Бог трогать файлы ports/Mk/bsd.port*.mk, если вы не хотите привести порт-менеджеров в ярость!

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