About this document ...

Введение в создание пакетов для дистрибутива GNU Debian/Linux

This document was generated using the translator Version 2K.1beta (1.48)

The command line arguments were:

latex2html deb.tex

The translation was initiated by Zhenja Kaluta on 2002-12-12

Zhenja Kaluta 2002-12-12

Control

Формат файла control используются повсеместно в debian. Каждый пакет (бинарных и исходных кодов) содержит информацию о себе в этом формате, базы apt и dpkg хранятся в нем же.

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

Ключ: значение

Название поля -- регистронезависимо, но принято записывать его строчными буквами начиная с заглавной. Если значение многострочное, каждая новая строка должна начинаться с пробела. Чтобы отличить пустую строку в многострочном поле от границы между описаниями, следует использовать строку, состоящую из пробела и точки: `` .''.

Наиболее часто встречающиеся поля:

Package:

название бинарного пакета. Состоит из букв, цифр, знаков ``+'', ``-'', ``.''. Должно состоять как минимум из 2х символов, начинаться с буквы или цифры и быть не полностью из цифр. Также настоятельно рекомендуется, что бы имя состояло только из строчных букв.

Version:

Содержит версию пакета в формате

[epoch:]<upstream version>[-<debian revision>]

Maintainer:

Имя и e-mail ментейнера пакета.

Standards-Version:

Версия полиси, которому пакет удовлетворяет. Текущая -- 3.5.6.1.

Distribution:

В файле .changes указывает дистрибутив, для которого собирается пакет.

Зависимости:

См.

Description:

Описание пакета. Состоит из краткого одно строчного описания и много строчного.

Zhenja Kaluta 2002-12-12

Для чего нужна система управления пакетами

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

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

контроль файлов в системе и целостности программ1;

отслеживание зависимостей программных пакетов друг от друга и конфликтов между ними. См. ;

Zhenja Kaluta 2002-12-12

Дополнительные файлы пакета

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

conffiles

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

md5sums

список md5 сумм файлов пакета по одному файлу на строчку.

shlibs

список разделяемых библиотек, которые устанавливаются с пакетом по строчке на библиотеку в формате

library-name soname-version-number dependencies

Например:

libz 1 zlib1g (>= 1:1.1.3)

config/templates

файлы debconf. См. .

Zhenja Kaluta 2002-12-12

Формат двоичного пакета deb

Пакет deb(5) есть архив ar, состоящий из трех файлов:

debian-binary

Текстовый файл, содержит одну строку -- версию формата. На сегодня это -- 2.0.

control.tar.gz

архив tar.gz, содержит текстовые файлы с управляющей информацией. Их содержание будет рассмотрено позже.

data.tar.gz

архив tar.gz, содержит собственно сами файлы, входящие в пакет.

Zhenja Kaluta 2002-12-12

Формат пакета исходных кодов

Итак, задача: есть некая программа в исходных кодах (tarball), необходимо создать создать из него набор, пригодный для сборки deb. Этот процесс называется дебианизацией программы. Для того чтобы дебианизировать программу, нужно в дереве ее исходников создать каталог debian/ и положить туда файлы:

control

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

Source

Section

Maintainer

Build-Depends (См. )

Standards-Version

rules

- основной файл построения пакета. Представляет собой исполняемый файл, который обязательно долен принимать параметры clean, binary, binary-arch, binary-indep, и build. Они не должны быть интерактивными. Удобно делать его в виде Makefile'а (первой строкой которого будет #!/usr/bin/make -f)

changelog

- журнал изменений Debian-сборки пакета. Формат этого файла строго зафиксирован, поскольку из него различными инструментами извлекается информация о версии и приоритете сборки, об исправленных багах, личности сборщика и т.п. Для генерации первой записи в этом файле можно воспользоваться скриптом dch из пакета devscripts.

Zhenja Kaluta 2002-12-12

Lintian

Утилита проверки пакета на корректность. Проверяет наличие распространенных ошибок, а так же соответствие полиси. Пакет задается 3мя способами: по имени файла, имени пакета, файлом .changes.

Zhenja Kaluta 2002-12-12

Литература

developers-reference

debian-policy

fhs

maint-guide

Zhenja Kaluta 2002-12-12

Обзор полезных утилит

Subsections

lintian

Пакет devscripts

Zhenja Kaluta 2002-12-12

Пакет devscripts

debuild

- утилита построение пакета из исходников. Вызывает dpkg-buildpackage и lintian. Параметры каждому можно передать;

dch

- добавляет запись в debian/changelog, в случае необходимости, изменяет название каталога. 3 основных режима:

append добавляет пометку об изменении в текущую запись;

increment добавляет новую запись, увеличивает Debian релилз.

newversion точно задает версию;

debclean

очищает дерево исходников (зовет debian/rules clean);

debpkg

оболочка над dpkg, передвызовом dpkg становится рутом;

debrelease

оболочка над dupload и dput

Zhenja Kaluta 2002-12-12

По существующей файловой системе пакета

Создаем каталог DEBIAN, содержащий control информацию, создаем пакет dpkg -b

Zhenja Kaluta 2002-12-12

Ручное

Создать 3 файла и за'ar'ить.

Zhenja Kaluta 2002-12-12

Сборка с использованием debhelper

В debian существует достаточное количество инструментов, помогающих автоматизировать процесс дебианизации. Рассмотрим debhelper(1), как наиболее часто встречающийся и рекомендованный в developers-reference. Пакет debhelper представляет собой набор скриптов dh_*, облегчающие процесс конфигурирования и компиляции программы, инсталяции ее и сборки в результирующий deb. Для работы с debhelper рекомендую воспользоваться программой dh_make из пакета dh-make.

приводим название каталога исходников к виду, необходимому для dh_make(8): <название пакета>-<версия>;

в корне каталога исходников зовем dh_make(8). Например,

dh_make -c gpl -e mycool@e-mail.com

идем в debian/ и правим необходимые файлы, удаляем ненужные

Подробнее о последнем пункте. Рассмотрим ситуацию генерации single binary (есть еще варианты multiple binary, library и kernel module) dh_make сгенерирует rules таким образом, что программа будет устанавливаться в debian/tmp (либо в debian/tmp/package в случае multi-binary пакета). Рассмотрим файлы:

changelog

- Готовый файл с единственной записью ``Initial release''

conffiles.ex

- файл состоит из комментария о его использовании. К слову, в conffiles коментарии # не поддерживаются, поэтому их нужно удалить4.

control

- Этот шаблон необходимо обязательно заполнить в соответствии с указанными выше правилами оформления файла control. Кроме того, debhelper поддерживает набор макросов. Например, в Depends: можно записать

${shlibs:Depends}

вместо списка библиотек;

${misc:Depends}

макрос раскрывается многими программами debhelper. Например, если Вы используете dh_installdebconf, то Вам необходим debconf, для dh_installxfonts понадобятся xutils. Эти зависимости и будут автоматически сгенерированы;

${perl:Depends}

генерируется dh_perl и содержит список используемых модулей perl.

- в этом файле кроме лиценции указывается информация об upstream, то есть производителе программы (где взяли, кто написал).

cron.d.ex

- файл в формате crontab(5). Будет установлен скриптом dh_installcron в $(prefix)/etc/cron.d/<package>

dirs

- содержит относительные пути каталогов, необходимых пакету. Обрабатывается dh_installdirs (он создает указаные каталоги)

docs

- список файлов, которые dh_installdocs установит в usr/share/doc/<package>. Подерживает маски. Корнем является корень дерева исходников (не debian/).

emacsen-install.ex

- Следующие три необходимы, если вы debian'изируете пакет для [X]emacs. Устанавливаются dh_installemacsen. Скрипт инталяции.

emacsen-remove.ex

- скрипт деинталяции.

emacsen-startup.ex

- пример lisp-файла инициализации. Установится в site-lisp.d

ex.package.doc-base

- TODO: почитать :)

init.d.ex

- пример скрипта для init.d, если программа в нем нуждается. dh_installinit установит его в etc/init.d/<package>.

manpage.1.ex

- шаблон man. Обрабатывается dh_installman

manpage.sgml.ex

- шаблон sgml для генерации man.

menu.ex

- шаблон для системы меню debian. dh_installmenu установит его в usr/lib/menu/<package>. Файл (формат описан в menufile(5L)) состоит из строк вида

?package(package-name):var1=value var2=varlue2

Возможные переменные:

needs

- тип дисплея, на котором запускается программа. Например, needs=x11;

section

- секция меню. Например, section=Apps/Programming. Структура меню описана в menu-policy;

icon

- иконка;

title

- текст пункта меню. Например, title=''Coolprog'';

command

- команда, выполняемая при выборе пункта меню.

Пример строки:

?package(foo):needs=x11 section=Apps/Programming title="Foo" command=''foo -coolkey''

postinst.ex, postrm.ex, preinst.ex, prerm.ex

- шаблоны ментейнеровских скриптов.

README.Debian

- описание особенностей сборки и использования пакета, специфичных для Debian.

watch.ex

- шаблон для автоматического апдейта пакета.

rules

- шаблон файла построения пакета. Рассмотрим его подробнее.

TODO: Рассмотреть rules в комментариях. Рассказать в них о dh_* скриптах.

#!/usr/bin/make -f # Sample debian/rules that uses debhelper. # GNU copyright 1997 to 1999 by Joey Hess.

# Uncomment this to turn on verbose mode. #export DH_VERBOSE=1

# This is the debhelper compatibility version to use. export DH_COMPAT=3

# These are used for cross-compiling and for saving the configure script # from having to guess our platform (since we know it already) DEB_HOST_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)

В следующие строки дают возможность указав в переменной окружения DEB_BUILD_OPTIONS debug и/или nostrip собрать пакет с отладочной информацией.

ifneq (,$(findstring debug,$(DEB_BUILD_OPTIONS))) CFLAGS += -g endif ifeq (,$(findstring nostrip,$(DEB_BUILD_OPTIONS))) INSTALL_PROGRAM += -s endif

Правило для конфигурации. Не является обязательным, требуется из обязателного build. Исли пакет использует GNU autoconf (как тот, что я взял для примера), то вставит и вызов configure. В данном случае указано, что для построения файла config.status необходим файл configure и осуществить указанные действия.

Скрипт dh_testdir пытается проверить в нужном ли каталоге мы находимся (проверяет существование файлов debian/control и других)

config.status: configure dh_testdir

# Add here commands to configure the package. ./configure --host=$(DEB_HOST_GNU_TYPE) --build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr --mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info

От себя добавлю, что в большинстве случаев эта строчка не является целиком корректной. Необходимо в большинстве случаев добавлять -sysconfdir=/etc (аналогичная ситуация с /var)

Проверяем правило build-stamp, которое в свою очередь проверяет config-status. Этим добиваемся того, чтобы не производить перекомпиляцию пакета, если не было его переконфигурации.

build: build-stamp

build-stamp: config.status dh_testdir

# Add here commands to compile the package.

Собственно, сама сборка. Если необходимы дополнительные команды либо параметры make, их можно добавить сюда.

$(MAKE) #/usr/bin/docbook-to-man debian/package.sgml > mc.1

touch build-stamp

Правило очистки от предыдущей сборки dh_testroot проверяет, от рута ли мы собираем (используем fakeroot), dh_clean чистит дерево сборки от всевозможных core, backup'ов ...

clean: dh_testdir dh_testroot rm -f build-stamp

# Add here commands to clean up after the build process. -$(MAKE) distclean -test -r /usr/share/misc/config.sub && \ cp -f /usr/share/misc/config.sub config.sub -test -r /usr/share/misc/config.guess && \ cp -f /usr/share/misc/config.guess config.guess

dh_clean

Правило инсталяции скомпилированной програмы во временный каталог.

install: build dh_testdir dh_testroot dh_clean -k dh_installdirs

Инсталяция. На практике проще использовать

$(MAKE) DESTDIR=$(CURDIR)/debian/package

так как большинство autoconf программ это поддерживает.

# Add here commands to install the package into debian/package. $(MAKE) install prefix=$(CURDIR)/debian/package/usr

Построение пакета(ов). binary-indep - независимого от архитектуры, binary-arch - зависимого.

# 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

Раскоментируйте, если используете debconf. Проставит config и templates (в DEBIAN), и добавит код в скрипты.

# dh_installdebconf

Проставим доки, указанные в debian/docs в usr/share/doc/package

dh_installdocs

Проставим файлы, указанные параметрами в usr/share/doc/examples

dh_installexamples

Проставим файлы меню в usr/lib/menu/package (если мы реализуем меню, скажем, мы - wm, то проставим debian/menu-method в etc/menu-methods/package. Добавим код, вызывающий update-menus(1) (скрипт debian'овской системы меню) в инсталяционные скрипты.

dh_installmenu

Проставим debian/logrotate в etc/logrotate.d

# dh_installlogrotate

Емаксовые пакеты

# dh_installemacsen

debian/pam в etc/pam.d/package

# dh_installpam

Если мы устанавливаем обработчик mime, проставит debian/mime в usr/lib/mime/packages/package и добавит вызовы update-mime. См. mime-policy и mailcap(5)

# dh_installmime

debian/init -> etc/init.d/package + update-rc.d в скрипты.

# dh_installinit

debian/cron -> etc/cron.d

dh_installcron

man и info

dh_installman

dh_installinfo

сделаем симлинки на undocumented для тех man-страниц, которых нет. Полезен ключ -A.

# dh_undocumented

dh_installchangelogs ChangeLog

dh_link

dh_strip

Сожмем файлы (man, info ...) и поправим симлинки на них.

dh_compress

Установим пермишены в соответствии с полиси

dh_fixperms

Сгенерируем список устанавливаемых библиотек shlib

# dh_makeshlibs

Установим скрипты, shlibs и conffiles, сгенерированные предыдущими скриптами в DEBIAN.

dh_installdeb

Посчитаем зависимости от перловых библиотек.

# dh_perl

Посчитаем зависимости от библиотек для замены ${shlibs:Depend}

dh_shlibdeps

Сгенерируем файл control подставив макросы.

dh_gencontrol

Сгенерируем суммы.

dh_md5sums

Запакуем это дело в deb.

dh_builddeb

binary: binary-indep binary-arch .PHONY: build clean binary-indep binary-arch binary install

Для сборки можно воспользоваться скриптом debuild из devscripts, либо dpkg-buildpackage из dpkg-dev (debuild пользуется ею). Запустив debuild в корне исходников получим на уровне выше готовый deb.

Next: Сборка с использованием программ

Up: Создание пакета исходных кодов

Previous: Формат пакета исходных кодов

&nbsp Contents

Zhenja Kaluta 2002-12-12

Сборка с использованием dpkg

Создаем каталог debian и необходимые файлы руками. Делаем правильный rules, dpkg -b.

Zhenja Kaluta 2002-12-12

Сборка с использованием программ из dpkg-dev

скрипты debhelper во многих случаях зовут скрипты более низкого уровня из пакета dpkg-dev. делаем шаблоны в debian/, пропускаем через dpkg-*, dpkg-buildpackage -b

Zhenja Kaluta 2002-12-12

Система зависимостей Debian

Система управления пакетами Debian имеет достаточно гибкую систему контроля зависимостей. Зависимости задаются в виде перечисления необходимых пакетов через запятую, возможно указывать несколько альтернативных пакетов через ``|''. Возможно привязать пакет к версии: версия указывается в скобках со знаком отношения <<, <=, =, >=, >> перед номером версии. Пример:

Depends: libc6 (>= 2.2.1), exim | mail-transport-agent

Зависимости можно разделить на 2 типа: зависимости бинарных пакетов и зависимости сборки пакетов.

Subsections

Зависимости бинарных пакетов

Зависимости сборки

Zhenja Kaluta 2002-12-12

Скрипты ментейнера пакета и процедура инсталляции

Скрипты - необязательная часть, исполняются автоматически системой управления пакетами во время установки/удаления пакетов. Служат для конфигурации/деконфигурации пакета. Например, они создают системных пользователей, необходимых для функционирования пакета, либо создают конфигурационные файлы (на основе базы debconf, что предпочтительно, либо задавая вопросы самостоятельно), прописываю/удаляют программу из меню и т.д.

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

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

Параметры, с которыми вызываются скрипты:

preinst

install, upgrade, abort-upgrade

postinst

configure, abort-upgrade, abort-remove, abort-deconfigure

prerm

remove, upgrade, faled-upgrade, deconfigure

postrm

remove, purge, upgrade, failed-upgrade, abort-install, abort-upgrade, disappear

Процедура инсталляции проходит в 13 этапов3. Кратко, preinst и postrm зовутся, когда файлов пакета нет в файловой системе.

При корректной инсталяции порядок вызова следующий:

new-preinst install

<распаковываются файлы>

new-postinst install

При апгрейде:

old-prerm upgrade new-version

new-preinst upgrade old-version

<распаковываются файлы>

old-postrm upgrade new-version

<удаляются лишние файлы>

<заменяются основные файлы>

<заменяются скрипты>

<удаляются backup'ы>

<статус меняется на unpacked>

new-postinst configure

Zhenja Kaluta 2002-12-12

Создание двоичных пакетов deb из двоичных файлов

Subsections

По существующей файловой системе пакета

Ручное

Zhenja Kaluta 2002-12-12

Создание пакета исходных кодов

Subsections

Формат пакета исходных кодов

Сборка с использованием debhelper

Сборка с использованием программ из dpkg-dev

Сборка с использованием dpkg

Zhenja Kaluta 2002-12-12

Управляющие файлы двоичного пакета

Сюда входит файл control, скрипты и файлы подсистем debian.

Subsections

control

Скрипты ментейнера пакета и процедура инсталляции

Дополнительные файлы пакета

Zhenja Kaluta 2002-12-12

Зависимости бинарных пакетов

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

Depends

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

Pre-Depends

Также абсолютная зависимость, но более строгая. Не будет начинаться даже инсталляция пока эта зависимость не будет удовлетворена (необходима, если пакет используется, скажем, в инсталляционных скриптах)

Recomends

Строгая, но не абсолютная зависимость. Перечисляет пакеты, которые должны быть установлены с данным, кроме случаев необычных инсталляций. Например, kernel-sources настоятельно рекомендуют устанавливать gcc.

Suggests

Зависимость указывает на пакеты, не на шутку расширяющие функциональность данного. Например, те же kernel-sources указывают тут ncurses-dev так как конфигурировать с помощью make config не слишком весело.

Enchances

Имеет обратный смысл предыдущего. Перечисляет пакеты, функциональность которых расширяет данный пакет.

Conflicts

Указывает пакеты, вместе с которыми данный работать не может. Например, на машине может быть только один MTA, поэтому exim конфликтует с mail-transport-agent.

Replaces

Указывает пакеты, файлы которых заменяет. Если заменяет все файлы пакета, по пакет становится disappeared и помечается для удаления. Этим пользуются чтобы спровоцировать удаление конфликтующего пакета:

Provides: mail-transport-agent

Conflicts: mail-transport-agent

Replaces: mail-transport-agent

Provides

В debian существует система так называемых виртуальных пакетов. Большинство программ являются представителями какого либо класса (например, exim, sendmail, postfix - MTA). Поэтому в пакете, представляющем программу, полезно указать этот класс в поле Provides. Теперь, если какому-либо пакету необходима подобная функциональность, он может в поле Depends указать лишь название класса5 вместо того, чтобы перечислять все программы дистрибутива с подобной функциональностью. Так как физически не существует пакетов с такими именами, они называются виртуальными.

Zhenja Kaluta 2002-12-12

Зависимости сборки

Пакеты исходников могут потребовать наличия/отсутствия определенных бинарных пакетов для своей корректной сборки (например, компиляторов или библиотек)

Build-Depends,Build-Conflicts

зависимости должны быть удовлетворены в тот момент, когда debian/rules данного пакета вызывается с параметрами build, binary, binary-arch, build-arch, build-indep и binary-indep.

Build-Depends-Indep,Build-Conflicts-Indep

Zhenja Kaluta 2002-12-12