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

Возьмем приведенный выше пример. Допустим, у нас имеются веб-сайты 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.Появилась возможность задавать опции в полноэкранном текстовом режиме

В результате строка запуска сборки порта может выглядеть, например, таким образом:

# make WITHOUT_IMAGEMAGICK_JPEG=yes WITH_WINDOWS_FONT_DIR=/tmp/blabla WITHOUT_IMAGEMAGICK_PNG=yes WITHOUT_IMAGEMAGICK_BZIP2=yes…