Рашид Ачилов - Создаем порт для FreeBSD своими руками. Часть II

Рашид Ачилов

Создаем порт для FreeBSD своими руками

Часть II: расширенные возможности

В первой части статьи мы рассмотрели основные вопросы создания порта для FreeBSD своими руками. Но система сборки программ, используемая во FreeBSD, имеет значительно большие возможности, чем те, которые мы задействовали. Какие это возможности и как их использовать в своих портах?

Расширенные возможности системы

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

Расширенные возможности системы сборки портов, которые мы не использовали в первой части и которые можно использовать, это:

• Многофайловые дистрибутивы с возможностью отбора файлов в зависимости от заданного набора переменных.

• Внешние патчи, которые можно подключать в зависимости от заданного набора переменных.

• Задание параметров сборки порта с помощью полноэкранного текстового режима OPTIONS, с возможностью дальнейшего хранения и редактирования этих параметров.

• Дополнение или замена части процедур создания программы из порта.

Возможность работы с многофайловыми дистрибутивами позволяет указать, с какого из перечисленных сайтов нужно загружать указанный файл. Допустим, программа состоит из файлов file1.tgz и file2.tgz. File1.tgz присутствует только на двадцатом из перечисленных MASTER_SITES, в то время как file2.tgz — всюду. Система будет попусту обшаривать девятнадцать сайтов. Это не страшно, когда делается автоматом, но ужасно нервирует, когда спешишь. Кроме того, в зависимости от заданного набора параметров можно включать или исключать некоторые компоненты. Это особенно существенно, когда эти компоненты весят десятки мегабайт (например, порт editors/openoffice2).

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

Задание параметров сборки порта значительно повышает удобство работы с ним. Многие порты имеют не один десяток переменных «WITH_FOO=yes WITHOUT_BAR=yes», которые не то, что набрать в командной строке — запомнить непросто! Например, порт graphics/ImageMagick имеет 26 переменных типа «WITHOUT_IMAGEMAGICK_SOME=yes». Если бы автор порта сделал экран опций, работать с таким портом было бы гораздо проще.

Дополнение или замена части процедур создания порта — это крайне важные возможности системы. Перечень основных шагов системы, выполняемых при создании программы, был уже приведен в.[1] Но возможно ли, скажем, установить через систему портов бесплатную программу с закрытым исходным текстом? Думаете, нет? Можно. И именно для этого были реализованы механизмы дополнения и/или замены части процедур сборки порта. Мы рассмотрим их в соответствующем разделе.

А теперь пора перейти от слов к делу.

Многофайловые дистрибутивы и внешние патчи

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

В этом случае файлы дистрибутива просто перечисляются:

DISTFILES= file1.tar.bz2

file2.tar.bz2

file3.tar.bz2

при этом все данные файлы будут последовательно запрошены со всех перечисленных сайтов в MASTER_SITES и с основного сайта FreeBSD, если они не будут обнаружены. Но что же делать тем, кто не имеет собственных серверов и размещает файлы на публичных хостингах? Для этого в системе есть специальная возможность связывания определенных файлов и определенных сайтов так, чтобы при поиске файлов система просматривала только некоторые определенные сайты. Эта возможность называется «MASTER_SITES: n».

Возьмем приведенный выше пример. Допустим, у нас имеются веб-сайты www.foobar.com и www.nichego.net. Сайт www.foobar.com находится за рубежом, имеет быстрый и надежный канал. www.nichego.net находится в г. Тьмутаракани и подключен к Интернету через модем на 28.8 кБит. Как сделать так, чтобы система брала только file1.tar.gz с www.nichego.net, а остальные — с www.foobar.com? Нужно ассоциировать метки и с файлами, и с сайтами:

DISTFILES= file1.tar.bz2

file2.tar.bz2:foobar

file3.tar.bz2:foobar

MASTER_SITES= http://www.foobar.com/:foobar

http://www.nichego.net

Если метка отсутствует, считается, что файл (сайт) имеет метку по умолчанию DEFAULT. Явно задавать ее не следует, разве что требуется перечислить несколько групп и DEFAULT в том числе. Система свяжет DISTFILES и MASTER_SITES, используя метки, и загрузит файлы в следующей последовательности: сначала file1.tar.bz2 с http://www.nichego.net, потом file2.tar.bz2 и file3.tar.bz2 с http://www.foobar.com.

Можно было бы сделать, чтобы и файл file1.tar.bz2 тоже сначала проверялся на http://www.foobar.com, а уже потом — на http://www.nichego.net. Для этого нужно www.foobar.com включить также и в группу DEFAULT:

MASTER_SITES= http://www.foobar.com/:foobar,DEFAULT

Один и тот же файл может входить в несколько групп. Равным образом в одну группу могут входить несколько файлов. Естественно, допускается использование подстановки переменных:

GSI_VERSION= 2005-01-20

DISTFILES+= gsi-$(GSI_VERSION)-sorted.txt.bz2:oorus,oorus2

INFRA_PATCHEXT= OOo_1.1.4_infra_patches

DISTFILES+= ${INFRA_PATCHEXT}.tar.gz: DEFAULT,oorus

MASTER_SITES+= http://ootrans.i-rs.ru/out/:oorus

MASTER_SITES+= ftp://ftp.i-rs.ru/pub/openoffice/1.1.4/ru/:oorus2

MASTER_SITES+= ftp://ftp/granch.ru/pub/openoffice

В данном фрагменте файл gsi-2005-01-20-sorted.txt.bz2 будет скачиваться сначала с http://ootrans.i-rs.ru/out, потом с ftp://ftp.i-rs.ru/pub/openoffice/1.1.4/ru, а файл OOo_1.1.4_infra_patches.tar.gz — сначала с ftp://ftp.i-rs.ru/pub/openoffice/1.1.4/ru, потом с ftp://ftp.granch.ru/pub/openoffice.

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

Например, это не было сделано в порту editors/openoffice-1.1, и в результате чего исходные тексты Mozilla Suite (обьема немалого — 35 Мб) загружались независимо от желания пользователя ее использовать.

Использование внешних патчей во многом похоже на загрузку файлов исходного кода программы, только здесь используются переменные PATCH_SITES и PATCHFILES:

PATCH_SITES= ftp://ftp.cis.upenn.edu/pub/xv/

PATCHFILES= ${DISTNAME}.JPEG-patch ${DISTNAME}.TIFF-patch

croppad.patch grabpatch vispatch

deepcolor.patch gifpatch exceed_grab.patch

tiff1200.patch gssafer.patch

Имейте в виду, что патчи, заданные в PATCHFILES, применяются до применения патчей из подкаталога files! То есть последовательность действий будет выглядеть так:

===> Patching for xv-3.10a_5

===> xv-3.10a_5 depends on file: /usr/local/bin/perl5.8.7 — found

===> Applying distribution patches for xv-3.10a_5

===> Applying FreeBSD patches for xv-3.10a_5

Когда стоит использовать внешние патчи? Разработчики обычно используют их, чтобы избежать выпуска нового релиза программы (так обычно поступают разработчики Squid — вместо выпуска нового релиза они выкладывают патчи значительного обьема), авторы портов, не являющиеся разработчиками программы, — чтобы внести в исходный текст изменения, с которыми автор может быть не согласен, если они достаточно обьемные и их нельзя поместить непосредственно в дерево портов, для расширения функциональности и т. д.

Следует учесть то, что если патч не создан с использованием стандартной процедуры diff, то его нельзя применять описанным методом и необходимо предусмотреть для него специальную обработку (см. пример в описании порта для OpenOffice).

Опции

Если программа сложная, то, как правило она предлагает множество различных вариантов построения — с использованием такой-то возможности, без использования такой-то возможности… Некоторые порты сначала проводят «автоматическое обнаружение» некоторых задействуемых компонент, а уже потом устанавливают переменные, включающие или отключающие различные возможности, а некоторые оставляют это на усмотрение пользователя. Если пользователь об этом не подозревает, то он может так никогда ими и не воспользоваться. Одним из примеров того, как делать ни в коем случае не надо, я считаю порт graphics/ImageMagick. Мало того, что там 26 переменных, так еще пользователь даже не оповещается, что они вообще есть!

Рисунок 1. Появилась возможность задавать опции в полноэкранном текстовом режиме