архив

Zenwalk
Приобщение к Linux

Алексей Федорчук

2008-06-25

назад | к началу | вперед

ZENBUILD

и с чем его едят.

Что такое ZENBUILD, вкратце уже говорилось: это файл, содержащий формализованное описание действий, которые необходимы для сборки пакета, предназначенного для установки в дистрибутиве Zenwalk. А едят его с текстовым редактором, ибо он представляет собой простой текстовый файл, в котором нужно просто заполнить строки, соответствующие реалиям собираемого пакета.

Для облегчения жизни сборщика при установке пакета buildpkg, как уже говорилось, устанавливается и прототип этого файла — /etc//buildpkg/ZENBUILD, специально предназначенный для всех издевательств, которые составят предмет настоящего раздела. Описание этих издевательств будет дано на примере сборки реального пакета — flwm версии 1.02; мысль собрать его появилась у меня после прочтения статьи о легких оконных менеджерах, в которой места для него почему-то не нашлось, как не обнаружился этот легчайший из лёгких менеджеров окон и в официальных репозиториях Zenwalk и его пользовательском репозитории.

Сборку пакета мы начинаем с того, что создаём каталог, где будут происходить все дальнейшие события: 

$ mkdir ~/path2/flwm

И первым событием будет помещение в него прототипа файла ZENBUILD. Это можно сделать простым копированием 

$ cp /etc//buildpkg/ZENBUILD ~/path2/flwm/

Но если последовательно следовать пути Дзэн, то лучше это сделать так: 

$ buildpkg -g

Теперь извлекаем из закромов Родины любимый текстовый редактор. Если такового пока не имеется, рискну предложить на эту роль Geany — кстати, это один из способов убедиться в его несравненных достоинствах для достижения поставленной цели.

Первозданный ZENBUILD выглядит следующим образом: 

#Maintainer: Name <email@address.com>
#Former Maintainer(s): Name <email@address.com>
#Anything commented out is optional and can be deleted.


pkgname=
pkgver=
pkgrel=
zenver=
arch=i486
source=()
#sourcetemplate=http://users.zenwalk.org/user-accounts/pnboy/$pkgname/$pkgver/
#docs=("readme" "install" "copying" "changelog" "authors" "news" "todo")
#url=
#extradepends=()
#lessdepends=()
#dotnew=()
#CFLAGS=
#CXXFLAGS=
#options=('noextract')


#doinst() {
#
#}


slackdesc=\
(
#|-----handy-ruler------------------------------------------------------|
""
)


build() {
	cd $startdir/src/$pkgname-$pkgver
	./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc
	make || return 1
	make install DESTDIR=$startdir/pkg
}

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

Смысл первой секции -- 

#Maintainer: Name <email@address.com>
#Former Maintainer(s): Name <email@address.com>
#Anything commented out is optional and can be deleted.

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

Вторая секция — от строки pkgname до source включительно — включает переменные, значения которым должны быть определены столь же непременно (Mandatory), сколь обязательным было исполнение мандатов Великого Ленина. Этими значениями будут:

  • авторское название пакета (pkgname) и
  • его версия (pkgver) в авторской же нумерации;
  • релиз конкретной сборки (pkgrel) и
  • версия сборки пакета для Zenwalk'а (zenver); обращаем внимание, что порядок тут обратный — то есть релизы существуют внутри Zen-версий;
  • архитектура целевой платформы (arch); для скомпилированных пакетов, написанных на языках высокого уровня, это, как правило, i486 (опеределяется умолчальным значением флага gcc -march), реже — i686; для пакетов, не требующих компиляции, таких как сценарии оболочки, наборы шрифтов, сборники документации, переменной arch присваивается значение noarch (то есть независимо от архитектуры);
  • URL сайта (сервера), с которого следует получить исходники пакета (source), с указанием точного имени файла архива и пути к нему; если для сборки пакета требуются дополнительные компоненты, такие как патчи, то здесь же указываются адреса, с которых они должны быть получены.

В результате заполнения всех обязательных полей эта секция для нашего примера (пакета flwm-1.02), Mandatory-секция приобретёт следующий вид: 

pkgname=flwm
pkgver=1.02
pkgrel=1
zenver=1
arch=i486
source=("http://flwm.sourceforge.net/$pkgname-$pkgver.tgz")

Обращаем внимание, что в прототипе ZENBUILD ни одна строка не закомментирована — и все они должны остаться таковыми в итоговом файле.

Следующая секция — опциональная (Optional) или, скорее, дополнительная. Здесь, напротив, ремарками закрыты все строки. Однако, как станет ясно из дальнейшего изложения, это не значит, что все они не обязательны. Те, которым необходимо или желательно придать значения, должны быть раскомментированы.

Смысл ополнительных переменных следующий:

  • #sourcetemplate — URL, по которому расположены шаблоны файлов официального майнтайнера данного пакета;
  • #docs — перечень файлов, которые должны быть помещены в каталоги для документации, таких как readme, install, copying и так далее;
  • #url — официальный сайт проекта;
  • #extradepends — «жесткие» зависимости пакета; если таковые имеются, они должны быть вписаны сюда, и строка, таким образом, становится обязательной; эти «жесткие» зависимости включаются в файл .dep;
  • #lessdepends — «мягкие» зависимости пакета, добавляются по желанию или разумению майнтайнера; не включаются в файл .dep;
  • #dotnew — перечень конфигурационных файлов, которые должны быть помещены в каталог /etc/;
  • #CFLAGS — флаги компиляции для программ на чистом Си; по умолчанию применяются флаги "-02 -march=$arch -mtune=i686"; если хотя бы один из них изменяется, (например, -O2 на -O3), то в этой строке необходимо перечислить и те из умолчальных флагов, которые остаются неизменными;
  • #CXXFLAGS — флаги компиляции для программ на Си++, определяются, как и в предыдущем пункте;
  • #options — опции, определяющие ряд дополнительных действий (или, чаще, «бездействий») в ходе выполнения сценария buildpkg; так, опция noextract запрещает распаковку архива (в этом случае эта операция должна быть предусмотрена в функции build(), о которой будет сказано ниже), опция norequiredbuilder предотвращает автоматическое определение зависимостей, опция requiredbuilderflatdeps предписывает ограничиться только непосредственными зависимостями, без учёта «зависимостей зависимостей»;
  • doinst() — перечень команд, которые должны быть выполнены после установки.

В нашем примере с пакетом flwm вся опциональная секция свелась к четырём строкам: 

docs=("readme")
url="http://flwm.sourceforge.net/"
extradepends=('fltk' 'xcb')
options=('requiredbuilderflatdeps')
Отступление. В свете того, что говорилось на протяжении этой и ряда предшествующих глав, может возникнуть резонный вопрос: а откуда же берутся сведения о необходимых зависимостях? Ведь ранее неоднократно подчеркивалось, что отслеживание их — одна из самых сложных задач, которые призваны решать системы построения пакетов и управления ими.

Ответ, как всегда, двоякий. Во-первых, для простых пакетов типа нашего flwm их можно просто знать — в этом часто помогут разработчики, приводящие сведения о зависимостях своих пакетов на сайтах проекта. Так, автор оконного менеджера flwm, Bill Spitzak (транскрибировать его фамилию не берусь), на своем сайте указывает, что для сборки этого пакета необходима библиотека fltk (разработанная им же).

Однако в отношении сложных пакетов со множеством зависимостей этот подход может не дать результата. И тогда на помощь прходит ещё один, специальный, скрипт — requiredbuilder. Если выполнить его с указанием текущего каталога в качестве аргумента, то последует серия запросов такого типа (на примере flwm): 

$ requiredbuilder .
Do you want to add these dependencies to the slack-required?
Reply yes or no:


cxxlibs | gcc-g++
Do you want to add this dependency? [yes] y
fltk
Do you want to add this dependency? [yes] y
gcc
Do you want to add this dependency? [yes] y
xcb
Do you want to add this dependency? [yes] y
xorg-libs
Do you want to add this dependency? [yes] y
Ответы будут отражены в файле ./install/slack-required, откуда их легко будет извлечь для использования в построении ZENBUILD.

Вернёмся, однако, к заполнению ZENBUILD. Следующая секция — slackdesc — представляет собой описание пакета, выполненное по правилам, которые приняты в Slackware. Согласно этим правилам, первая строка должна содержать имя пакета (определяемое через значение переменной pkgname) и его (очень) краткое описание, примерно такое: 

"$pkgname - fast light window manager"

Далее идёт описание более подробное. Оно также должно быть разбито на строки, каждая из которых заключается в кавычки и должна содержать не более 70 символов. Всех же строк в slackdesc должно быть не более 10, причём — по-английски, почему я и воздержусь от приведения примера.

И, наконец, последняя секция — функция build(), которая собственно и описывает процесс сборки пакета. В прототипе файла ZENBUILD она выглядит так: 

build() {
	cd $startdir/src/$pkgname-$pkgver
	./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc
	make || return 1
	make install DESTDIR=$startdir/pkg
}

Можно видеть, что содержимое функции build() — те самые три магических заклинания, о которых шла речь в первом разделе этой главы. Опции конфигурирования определяют корневые каталоги для установки собранных компонентов (--prefix=/usr), модифицируемых файлов (--localstatedir=/var) и общесистемных каталогов. В ряде случаев в этой функции ничего менять не надо — именно так обстоит дело с нашим примером, пакетом flwm. Однако если сборщик пакета полагает необходимым включить какие-либо дополнительные функции или, напротив, отключить те из них, которые включены по умолчанию, то задать соответствующие опции конфигурирования следует именно здесь в виде: 

./configure --prefix=/usr --localstatedir=/var --sysconfdir=/etc \
	--with-PACKAGE --without-PACKAGE \
	--enable-FEATURE  --disable-FEATURE

Подробности по использованию опций with/without и enable/disable с конкретными примерами можно найти в главе 14 книги Введение в POSIX'ивизм.

назад | к началу | вперед