Статья с http://tigro.info/blog/ о сборке deb пакетов.
Для сборки пакета нам понадобятся debhelper, dh-make, devscripts, fakeroot, а также необходимые компиляторы и интерпретаторы. Кроме того нам нужна программа, которую будем компилировать. Сам тарбол нам как бы и не нужен, нам нужно только дерево исходников, которое необходимо распаковать. Главный каталог должен называться следующим образом: имяпакета-версияпакета, в противном случае возникнут проблемы.
В итоге у нас должны получиться бинарные файлы, исходник *orig*tar.gz, *diff*gz* и файлы .dsc и .changes. Возможно обойтись без файлов *orig*tar.gz и *diff*gz* заменив их одним тарболом, в котором находятся все служебные файлы, однако начиная с версии Debian 4.0 подобные ухищрения не приветствуются.
Итак, я для удобства рекомендую создать в вашем домашнем каталоге папку, допустим, BUILD, в ней для каждого пакета создавать каталог по его имени, и уже внутри последнего каталога размещать дерево исходников. Для чего так сложно? Потому, что собранные пакеты будут помещаться на уровень выше дерева и у вас скоро весь каталог BUILD забьётся кучей файлов.
Если вы хотите использовать Цифровую подпись, то необходимо добавить в ваш файл .bashrc следующие строки:
export EMAIL=your@gpg.email export DEBFULLNAME="YOUR GPG NAME" export DEBEMAIL=your@gpg.email
Имя и почтовый адрес должны быть такими же, какими вы их задали при создании GPG ключа. Если вы создали ещё и описание, то его тоже необходимо указать в переменной DEBFULLNAME.
Итак, для начала необходимо создать служебные файлы. Для этого нужно зайти в каталог исходников и отдать команду dh_make --createorig. Вам необходимо выбрать нужный тип пакета. Если у вас будет только один бинарный пакет, то нажимаем s, если несколько — то l. Для модулей ядра нужно выбрать k. О cdbs (b) мы поговорим как-нибудь потом.
Можете также вызывать команду
dh_make
вместе с ключом
-c
чтобы указать лицензию пакета.
Мы сперва рассмотрим пакет, содержащий несколько бинарников (то, что обычно ни в каких документациях не рассматривается). А потом скажем несколько слов относительно single binary.
После запуска dh_make создастся каталог debian, в котором будет лежать довольно большое количество файлов. Все файлы *.ex и *.EX можно в принципе удалить сразу и создавать только по мере надобности.
В файле control указываются все необходимые параметры. Он делится на секции Source и Package. Секций Package может быть несколько в зависимости от того сколько бинарных пакетов получится при сборке. Ниже приведён пример файла control для пакета liferea:
Source: liferea
Section: gnome
Priority: optional
Maintainer: Franz Pletz <fpletz@franz-pletz.org>
Uploaders: Luis Rodrigo Gallardo Cruz <rodrigo@nul-unu.com>
Build-Depends: autotools-dev, debhelper (>> 4.0.0), libgtkhtml2-dev
Standards-Version: 3.7.2.0
Package: liferea
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, liferea-xulrunner (=${Source-Version}), dbus-1-utils
Description: feed aggregator for GNOME
Liferea is a simple FeedReader clone for GNOME. It is a reader for
RSS/RDF feeds which also supports CDF channels, Atom/Echo/PIE feeds and
OCS directories.
.
Liferea is an abbreviation for Linux Feed Reader.
.
Homepage: http://liferea.sourceforge.net/
Package: liferea-xulrunner
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Provides: liferea-mozilla, liferea-gtkhtml
Conflicts: liferea-mozilla (<< 1.0.17-1), liferea-gtkhtml (<< 1.0.27-2)
Replaces: liferea-mozilla (<< 1.0.17-1)
Description: xulrunner-based rendering library for Liferea
Liferea is a simple FeedReader clone for GNOME2. It is a reader for
RSS/RDF feeds which also supports CDF channels, Atom/Echo/PIE feeds and
OCS directories.
.
Liferea is an abbreviation for Linux Feed Reader.
.
Homepage: http://liferea.sourceforge.net/
Package: liferea-mozilla
Architecture: all
Depends: liferea-xulrunner
Description: transitional dummy package
Previous versions of liferea had several rendering engines to choose from.
This is a dummy package to ease transition from those versions.
.
It can be safely removed from your system after updating.
Package: liferea-gtkhtml
Architecture: all
Depends: liferea-xulrunner
Description: transitional dummy package
Previous versions of liferea had several rendering engines to choose from.
This is a dummy package to ease transition from those versions.
.
It can be safely removed from your system after updating.
Разберём его поподробней. Итак, в секции Source указывается имя исходника, секция (Section), к которой пакет будет отнесён в репозитории, Priority — приоритет, подробнее смотреть здесь. Maintainer и Uploaders — думаю без вопросов, Build-Depends — пакеты необходимые при сборке пакета, Standards-Version — версия документа Debian-Policy (не нужно трогать).
Далее идёт описание для бинарного пакета, Packages — его имя, Architecture: архитектура пакета, может быть any (сама превратится в нужную платформозависимую архитектуру) и all (платформонезависимую), Depends — зависимости которые обязательно требуются для установки пакета (благодаря двум переменным в этом поле зависимости появятся автоматически, однако иногда следует добавлять их вручную), Description — описание пакета, причём в первой строке используется краткое описание, а в остальных строках, начиная с пробела, длинное. Новые абзацы отделены строкой с точкой.
По поводу зависимостей. Существуют ещё два типа зависимостей Suggests и Recommeds. Первый тип зависимостей нацелен на расширение возможностей нашего пакета, второй настоятельно рекомендует установить данные пакеты. Aptitude ставит зависимости Recommeds по умолчанию, apt-get не обрабатывает ни те, ни другие. Существуют также Pre-Depends, но их использовать не рекомендуется.
В зависимостях могут применяться указания версий, как видно из примера. Допустимыми символами сравнения являются: <<, <=, =, >=, и >> для строго раньше чем, раньше или равно, в точности равно, равно или позже и строго позже чем соответственно.
Также в control файле могут применяться следующие теги: Provides — дополнительное имя для нашего пакета (эдакое виртуальное), Replaces — список пакетов, которые будут удалены после установки нашего пакета, Conflicts — пакеты с которыми наш пакет заведомо конфликтует.
Вторым по важности файлом является файл rules. Именно в нем находится все необходимое для компиляции пакета и упаковки его в бинарные пакеты. Этот файл есть ничто иное, как скрипт make, с использованием команд dh_*.
В нем действительно много секций, и много строк, но нам нужно будет изменять секции config.status, build и install. В этих секциях, соответственно, необходимо прописать команды для конфигурации пакета (если они нужны), для его сборки и для установки. Если мысленно выкинуть всевозможные dh-команды, то скрипт становится не таким уж страшным. Правда dh-команды разумеется нужны. Ниже приведен файл rules:
#!/usr/bin/make -f
# Sample debian/rules that uses debhelper.
# GNU copyright 1997 to 1999 by Joey Hess.
CFLAGS = -g -O2
ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS)))
INSTALL_PROGRAM += -s
endif
config.status: configure
dh_testdir
cp -f /usr/share/misc/config.sub config.sub
cp -f /usr/share/misc/config.guess config.guess
CFLAGS="$(CFLAGS)" ./configure --prefix=/usr \
--mandir=\$${prefix}/share/man \
--sysconfdir=/etc --disable-gecko \
--disable-gtkhtml2 --enable-sm
ln -s $(CURDIR)/liferea.1 $(CURDIR)/debian/liferea-bin.1
ln -s $(CURDIR)/liferea.1 $(CURDIR)/debian/liferea-add-feed.1
build: build-stamp
build-stamp: config.status
dh_testdir
$(MAKE)
touch build-stamp
clean:
dh_testdir
dh_testroot
rm -f build-stamp config.log debian/liferea-bin.1 \
debian/liferea-add-feed.1
-$(MAKE) distclean
dh_clean
install: build
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs
GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1 $(MAKE) install \
DESTDIR=$(CURDIR)/debian/liferea
# add the debian menu icon
cp debian/liferea.xpm debian/liferea/usr/share/liferea/pixmaps/
# Link documentation
mkdir -p debian/liferea/usr/share/doc/liferea
ln -s ../../liferea/doc/html debian/liferea/usr/share/doc/liferea/html
dh_movefiles --sourcedir=debian/liferea
# Build architecture-independent files here.
binary-indep: build install
# We have nothing to do by default.
# Build architecture-dependent files here.
binary-arch: build install
dh_testdir
dh_testroot
dh_installchangelogs ChangeLog
dh_installdocs
dh_installman debian/liferea-bin.1 debian/liferea-add-feed.1
dh_installmenu
dh_gconf
dh_link
dh_strip
dh_compress
dh_fixperms
dh_installdeb
dh_shlibdeps
dh_gencontrol
dh_md5sums
dh_builddeb
binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install
Вообще при сборке deb-пакета следует привыкать к тому, что одно и тоже можно делать разными способами, что разумеется не упрощает задачу. Рассмотрим основные строки из файла rules.
В секции config.status идет обычный запрос на конфигурацию пакета. Обратите внимание, что вам необходимо правильно задавать каталоги, так как по умолчанию configure выбирает /usr/local. Секция build вызывает секцию build-stamp, в которой происходит обычный make ($(MAKE) = make).
Затем выполняется install. Там идет обычный make install и дополнительные команды для правильной установки данного пакета. Заметьте, что инсталляция происходит в каталог $(CURDIR)/debian/liferea, где $(CURDIR) каталог дерева исходников. Теперь одна из важных вещей. Нам необходимо разобрать файлы из общего каталога liferea по нашим бинарным пакетам. Именно для этих целей и служит команда dh_movefiles. В качестве параметра указывается каталог в который была произведена инсталляция. Если вы инсталлировали пакет в каталог $(CURDIR)/debian/tmp, то никаких параметров dh_movefiles передавать не нужно.
Все данные о том какие файлы в какие пакеты положить dh_movefiles берёт из файлов (в каталоге debian) название-бинарного-пакеты.install. Создайте их столько же, сколько будет бинарных пакетов и пропишите в них названия файлов с полным путём относительно каталога в который была установлена программа, но без первого слеша. Можно использовать маски.
После разбора файлов выполняется секция binary-arch, которая создаёт deb-пакет. В ней, например, видно, как устанавливаются man файлы.
В deb-пакете также могут присутствовать скрипты postinst, preinst, postrm и prerm, которые выполняются соответственно, после инсталляции, перед инсталляцией, после удаления и перед удалением. Для каждого из пакетов необходимо создать файл имя-бинарного-пакета.postinst и т. п. в них можно разместить любые команды.
Теперь рассмотрим changelog. Именно в нем мы будем указывать версию нашего пакета. Версией в Debian называется все, что идёт после имени пакета. В deb нет тегов release и epoch как в rpm, однако вы можете запросто задать что-то наподобие 3:1.0.4-15.feisty.0. До ":" идёт эпоха, после "-" идёт релиз. Файл changelog следует редактировать при помощи команды dch. Если её вызвать без параметра, то будет изменена последняя запись в changelog, а если dch -i, то будет добавлена новая:
liferea (1.0.27-2) unstable; urgency=low * Remove the GtkHTML rendering plugin. This plugin is basically unusable on 64bit architectures. liferea-gtkhtml is now just a dummy package for upgrades (Closes: #379900, #407152, #361376, #368866). * Remove upstream's NEWS file, it contains only version release dates. -- Luis Rodrigo Gallardo Cruz <rodrigo@nul-unu.com> Sun, 11 Feb 2007 21:18:16 -0600
Также в changelog вы можете менять принадлежность пакета к дистрибутиву (сразу после версии). В данно примере идёт unstable, в Ubuntu там должно быть что-то типа feisty, edgy и т. п.
Что касается single binary то там все намного проще. После команды dh_make, вам нужно подправить control и changelog. Возможно немного rules. И далее пакет соберётся сам собой.
Для сборки пакета нам понадобится команда debuild которую следует отдавать всё в том же каталоге исходников. После того, как пакеты соберутся, вы должны будете подписать пакет (если настроили GPG), вернее не пакет, а два текстовых файла, которые появятся в процессе сборки. Это файлы .dsc и .changes. Первый из них несёт информацию об исходнике, второй нужен только для помещения пакета в репозиторий.
У debuild есть параметр clean, который позволяет очистить дерево исходников и папку debian от ненужных файлов.
В этой статье я попытался передать основные принципы сборки deb пакетов, однако прекрасно понимаю, что нюансов здесь очень много, но описать их все я конечно же не смогу. Вам возможно следует почитать Руководство начинающего разработчика Debian, в котором некоторые аспекты изложены поподробней, а также Руководство по политике Debian. В следующей статье мы поговорим о том, как создавать репозитории для rpm и deb пакетов.