Версия для печати

Архив документации на OpenNet.ru / Раздел "Документация для Linux" (Многостраничная версия)
next up previous
Next: Для чего нужна система Up: Введение в создание пакетов Previous: Введение в создание пакетов


Contents


Zhenja Kaluta 2002-12-12

next up previous contents
Next: Contents   Contents

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

Дмитрий Бородаенко, Евгений Калюта



Zhenja Kaluta 2002-12-12

next up previous
Next: Для чего нужна система Up: Введение в создание пакетов Previous: Введение в создание пакетов


Contents


Zhenja Kaluta 2002-12-12

next up previous contents
Next: Формат двоичного пакета deb Up: Введение в создание пакетов Previous: Contents   Contents

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

Система управления пакетами и собственно сами пакеты решают несколько задач, облегчающих администрирование системы:
  1. выделение данных и программ в автономные единицы, которые можно целиком устанавливать, модернизировать и при необходимости удалять из системы, что облегчает, например, распространение программ;
  2. контроль файлов в системе и целостности программ1;
  3. отслеживание зависимостей программных пакетов друг от друга и конфликтов между ними. См. 6;


Zhenja Kaluta 2002-12-12

next up previous contents
Next: Управляющие файлы двоичного пакета Up: Введение в создание пакетов Previous: Для чего нужна система   Contents

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

Пакет deb(5) есть архив ar, состоящий из трех файлов:
debian-binary
Текстовый файл, содержит одну строку -- версию формата. На сегодня это -- 2.0.
control.tar.gz
архив tar.gz, содержит текстовые файлы с управляющей информацией. Их содержание будет рассмотрено позже.
data.tar.gz
архив tar.gz, содержит собственно сами файлы, входящие в пакет.

Zhenja Kaluta 2002-12-12

next up previous contents
Next: control Up: Введение в создание пакетов Previous: Формат двоичного пакета deb   Contents

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

Сюда входит файл control, скрипты и файлы подсистем debian.
Subsections
Zhenja Kaluta 2002-12-12

next up previous contents
Next: Формат пакета исходных кодов Up: Введение в создание пакетов Previous: Дополнительные файлы пакета   Contents

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


Subsections
Zhenja Kaluta 2002-12-12

next up previous contents
Next: Скрипты ментейнера пакета и Up: Управляющие файлы двоичного пакета Previous: Управляющие файлы двоичного пакета   Contents

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 указывает дистрибутив, для которого собирается пакет.
Зависимости:
См. 6
Description:
Описание пакета. Состоит из краткого одно строчного описания и много строчного.

Zhenja Kaluta 2002-12-12

next up previous contents
Next: Дополнительные файлы пакета Up: Управляющие файлы двоичного пакета Previous: control   Contents

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

Скрипты - необязательная часть, исполняются автоматически системой управления пакетами во время установки/удаления пакетов. Служат для конфигурации/деконфигурации пакета. Например, они создают системных пользователей, необходимых для функционирования пакета, либо создают конфигурационные файлы (на основе базы 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

next up previous contents
Next: Создание пакета исходных кодов Up: Управляющие файлы двоичного пакета Previous: Скрипты ментейнера пакета и   Contents

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

Если пакет использует библиотеки, устанавливает библиотеки, использует debconf, содержит конфигурационные файлы, то для его корректной инсталляции необходима дополнительная информация.
conffiles
список конфигурационных файлов пакета. Абсолютные пути, по одному на строчку. Они обрабатываются специальным образом.
md5sums
список md5 сумм файлов пакета по одному файлу на строчку.
shlibs
список разделяемых библиотек, которые устанавливаются с пакетом по строчке на библиотеку в формате
library-name soname-version-number dependencies

Например:

libz 1 zlib1g (>= 1:1.1.3)
config/templates
файлы debconf. См. 7.


Zhenja Kaluta 2002-12-12

... программ1
Не каждая система управления пакетами содержит информацию о целостности файлов, но система debian в текущем состоянии имеет необходимые средства.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... несколько2
-- если допустимо в контексте использования, например -- в файле debian/control пакета исходников, куда входит описание как исходного пакета, так и собираемых из него бинарных пакетов.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... этапов3
debian-policy, глава 6
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... удалить4
файлы smth.ex после редактирования следует переименовать в smth, если эти файлы нужны
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
... класса5
названия виртуальных пакетов строго регламентируются в virtual-package-names-list.txt
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

next up previous contents
Next: About this document ... Up: Введение в создание пакетов Previous: Пакет devscripts   Contents

Литература

  1. developers-reference
  2. debian-policy
  3. fhs
  4. maint-guide


Zhenja Kaluta 2002-12-12

next up previous contents
Up: Введение в создание пакетов Previous: Литература   Contents

About this document ...

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

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

Copyright © 1993, 1994, 1995, 1996, Nikos Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999, Ross Moore, Mathematics Department, Macquarie University, Sydney.

The command line arguments were:
latex2html deb.tex

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


Zhenja Kaluta 2002-12-12

next up previous contents
Next: lintian Up: Введение в создание пакетов Previous: Пара слов о debconf   Contents

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


Subsections
Zhenja Kaluta 2002-12-12

next up previous contents
Next: Литература Up: Обзор полезных утилит Previous: lintian   Contents

Пакет devscripts

debuild
- утилита построение пакета из исходников. Вызывает dpkg-buildpackage и lintian. Параметры каждому можно передать;
dch
- добавляет запись в debian/changelog, в случае необходимости, изменяет название каталога. 3 основных режима:
debclean
очищает дерево исходников (зовет debian/rules clean);
debpkg
оболочка над dpkg, передвызовом dpkg становится рутом;
debrelease
оболочка над dupload и dput

Zhenja Kaluta 2002-12-12

next up previous contents
Next: Сборка с использованием программ Up: Создание пакета исходных кодов Previous: Формат пакета исходных кодов   Contents

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

В debian существует достаточное количество инструментов, помогающих автоматизировать процесс дебианизации. Рассмотрим debhelper(1), как наиболее часто встречающийся и рекомендованный в developers-reference. Пакет debhelper представляет собой набор скриптов dh_*, облегчающие процесс конфигурирования и компиляции программы, инсталяции ее и сборки в результирующий deb. Для работы с debhelper рекомендую воспользоваться программой dh_make из пакета dh-make.
  1. приводим название каталога исходников к виду, необходимому для dh_make(8): <название пакета>-<версия>;
  2. в корне каталога исходников зовем dh_make(8). Например,
    dh_make -c gpl -e mycool@e-mail.com
  3. идем в 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.
copyright
- в этом файле кроме лиценции указывается информация об 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 contents
Next: Сборка с использованием программ Up: Создание пакета исходных кодов Previous: Формат пакета исходных кодов   Contents
Zhenja Kaluta 2002-12-12

next up previous contents
Next: Сборка с использованием dpkg Up: Создание пакета исходных кодов Previous: Сборка с использованием debhelper   Contents

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

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

next up previous contents
Next: Сборка с использованием debhelper Up: Создание пакета исходных кодов Previous: Создание пакета исходных кодов   Contents

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

Итак, задача: есть некая программа в исходных кодах (tarball), необходимо создать создать из него набор, пригодный для сборки deb. Этот процесс называется дебианизацией программы. Для того чтобы дебианизировать программу, нужно в дереве ее исходников создать каталог debian/ и положить туда файлы:
control
- управляющий файл пакета исходных кодов. Содержит абзац для пакета исходников и по абзацу на пакет бинариков, создаваемых из этого пакета. Управляющая иформация для пакета исходников обычно состоит из полей:
  1. Source
  2. Section
  3. Maintainer
  4. Build-Depends (См. 6)
  5. Standards-Version
rules
- основной файл построения пакета. Представляет собой исполняемый файл, который обязательно долен принимать параметры clean, binary, binary-arch, binary-indep, и build. Они не должны быть интерактивными. Удобно делать его в виде Makefile'а (первой строкой которого будет #!/usr/bin/make -f)
changelog
- журнал изменений Debian-сборки пакета. Формат этого файла строго зафиксирован, поскольку из него различными инструментами извлекается информация о версии и приоритете сборки, об исправленных багах, личности сборщика и т.п. Для генерации первой записи в этом файле можно воспользоваться скриптом dch из пакета devscripts.

Zhenja Kaluta 2002-12-12

next up previous contents
Next: Зависимости сборки Up: Система зависимостей Debian Previous: Система зависимостей Debian   Contents

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

Бинарные пакеты могут для свой корректной работы требовать наличия других, отсутствия других, а также рекомендовать к установке другие пакеты, вместе с которыми данные будут обеспечивать большую функциональность.
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

next up previous contents
Next: Пара слов о debconf Up: Система зависимостей Debian Previous: Зависимости бинарных пакетов   Contents

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

Пакеты исходников могут потребовать наличия/отсутствия определенных бинарных пакетов для своей корректной сборки (например, компиляторов или библиотек)
Build-Depends,Build-Conflicts
зависимости должны быть удовлетворены в тот момент, когда debian/rules данного пакета вызывается с параметрами build, binary, binary-arch, build-arch, build-indep и binary-indep.
Build-Depends-Indep,Build-Conflicts-Indep
зависимости должны быть удовлетворены в тот момент, когда debian/rules данного пакета вызывается с параметрами build, binary, binary-arch, build-arch, build-indep и binary-indep.

Zhenja Kaluta 2002-12-12

next up previous contents
Next: Зависимости бинарных пакетов Up: Введение в создание пакетов Previous: Ручное   Contents


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

Система управления пакетами Debian имеет достаточно гибкую систему контроля зависимостей. Зависимости задаются в виде перечисления необходимых пакетов через запятую, возможно указывать несколько альтернативных пакетов через ``|''. Возможно привязать пакет к версии: версия указывается в скобках со знаком отношения <<, <=, =, >=, >> перед номером версии. Пример:
Depends: libc6 (>= 2.2.1), exim | mail-transport-agent
Зависимости можно разделить на 2 типа: зависимости бинарных пакетов и зависимости сборки пакетов.
Subsections
Zhenja Kaluta 2002-12-12

next up previous contents
Next: Создание двоичных пакетов deb Up: Создание пакета исходных кодов Previous: Сборка с использованием программ   Contents

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

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


Zhenja Kaluta 2002-12-12

next up previous contents
Next: По существующей файловой системе Up: Введение в создание пакетов Previous: Сборка с использованием dpkg   Contents

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


Subsections
Zhenja Kaluta 2002-12-12

next up previous contents
Next: Ручное Up: Создание двоичных пакетов deb Previous: Создание двоичных пакетов deb   Contents

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

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

next up previous contents
Next: Система зависимостей Debian Up: Создание двоичных пакетов deb Previous: По существующей файловой системе   Contents

Ручное

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


Zhenja Kaluta 2002-12-12

next up previous contents
Next: Обзор полезных утилит Up: Введение в создание пакетов Previous: Зависимости сборки   Contents


Пара слов о debconf


Zhenja Kaluta 2002-12-12

next up previous contents
Next: Пакет devscripts Up: Обзор полезных утилит Previous: Обзор полезных утилит   Contents

lintian

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