DEBIAN/copyright: © / лицензия

Текст лицензии. Файл не обязателен, но лучше подчеркнуть своё авторство 😉

DEBIAN/changelog: история изменений

Changelog в специальном формате: используется dpkg для получения номера версии, ревизии, дистрибутива и важности пакета. Лучше посмотреть в официальной документации 😉 а я лишь приведу пример:
supersh (1.0-1) stable; urgency=medium

— o_O Tync Sun, 13 Dec 2009 00:11:46 +0300

DEBIAN/rules: правила компиляции

Используется для управления компиляцией пакета: это когда Architeture: source 🙂
См. официальную документацию

DEBIAN/conffiles: список файлов конфигурации

Обычно пакеты содержат болванки конфигурационных файлов, например, размещаемых в /etc. Очевидно, что если конфиг в пакете обновляется, пользователь потеряет свой отредактированный конфиг. Эта проблема легко решается использованием папок типа «config.d», содержимое которых включается в основной конфиг, заменяя собой повторяющиеся опции.
Файл «DEBIAN/conffiles» позволяет решить проблему иначе: он содержит список файлов конфигурации (по одному на строке). Если в текущей версии пакета один из этих файлов обновляется, то пользователь получает предупреждение о конфликте версий конфигов, и может выбрать: удалить, заменить, или сделать merge.
С этой ситуацией наверняка сталкивался каждый линуксоид, копавшийся в конфигах 🙂 А ноги растут отсюда.
На каждой строке должен быть полный абсолютный путь до каждого конфига. Например:
/etc/supersh/init.conf
/etc/supersh/actions.conf

DEBIAN/dirs: список папок для создания

«Список абсолютных путей к папкам, которые требуются программе, но по каким-либо причинам не создаются.» — гласит официальная документация. На практике – здесь перечисляются все папки, так или иначе используемые программой: и где лежат бинарники, и которые используются программой.
По одной на строке. Например:
/var/log/supersh
/var/lib/supersh
Удобно использовать для создания нескольких пустых папок.

DEBIAN/menu: создание пунктов меню

UPD: Правильный способ добавления пункта меню

DEBIAN/md5sums: контрольные суммы файлов

DEBIAN/watch: мониторинг сайта, откуда была скачана прога

Функция полезна, если Вы мэйнтейните от нескольких десятков пакетов, и уследить за всеми обновлениями сложно.
Файл содержит инструкции для программ uscan и uupdate. Используя эту возможность, можно следить за сайтом, откуда были получены исходники пакета, и обеспечивать контроль качества дистрибутива в целом.
Пример:
# Site Directory Pattern Version Script
ftp.obsession.se /gentoo gentoo-(.*)\.tar\.gz debian uupdate

И ещё пример для uscan(1):
version=3
madwimax.googlecode.com/files/madwimax-(.*)\.tar\.gz

Лучше почитайте официальную документацию, такие мощные вещи нечастно требуются простым смертным 🙂

DEBIAN/cron.d: инсталляция заданий cron

DEBIAN/inid.d: init-скрипт

В этот файл пишется содержимое init-скрипта. О написании init-скриптов в инете можно найти

Скриптинг

Мы подошли к самому интересному: встраиванию скриптов в deb пакеты. Скрипты позволяют управлять установкой, переустановкой и удалением пакета, выполняя действия, которые нельзя сделать простым копированием файлов в правильные места. Это может быть скачивание дополнительных файлов (как это делает flash-installer), изменение существующих, а также — вывод интерактивных (GUI или ncurses) диалогов, позволяющих пользователю сконфигурировать пакет под себя: например, mysql спрашивает какой установить пароль для root.
Все скрипты выполняются от пользователя root (а как же ещё :). Также они получают аргументы (которые обрабатывать не обязательно), конкретизирующие на каком именно этапе находится установка. Подробнее об этом здесь.

DEBIAN/(preinst|postinst|prerm|postrm): скрипты установки

exit 0

WARNING: болванка пока не тестировалась широко, проверьте лишний раз! На невозможность отладки наткнулся совсем недавно 🙂

DEBIAN/templates: шаблоны для диалогов

Как уже было сказано, в скрипте DEBIAN/config можно задавать пользователю вопросы: ввести строку, выбрать один из вариантов, поставить галочку,… Этим занимается «библиотека» bash функций debhelper пакета debconf, умеющая кроме этого ещё массу полезных вещей. Здесь их не рассматриваю 🙂
Файл DEBIAN/templates содержит данные, используемые при выводе диалоговых окон (GUI или ncurses). Файл содержит блоки, разделённые пустой строкой. Каждый блок определяет ресурсы, используемые в одном конкретном диалоговом окне.
Шапка для всех типов диалогов стандартная:
Template: supersh/template-name
Type: string
Default: Default-value
Description: Dialog-title
␣Dialog-text

Template — уникальный (в пределах одного пакета) идентификатор шаблона. Если в скрипте нужно вызвать определённый диалог — используется именно это имя.
Type — тип шаблона. Определены такие типы: string, password, boolean, select, multiselect, text, note, error.
Default-value — значение по умолчанию: пользователь может просто согласиться с ним.
Description — как и в контрольном файле, состоит из двух полей: короткое описание, и длинный текст. Первое — это заголовок «окна», второе — более развёрнутое описание того, что требуется от пользователя. Рекомендуется не использовать слов вроде «введите», а сразу суть: «Приветствие скрипта», «Точка монтирования»,…

Основы использования debconf и debhelper

# Подключение команд debconf
. /usr/share/debconf/confmodule

Собираем пакет! 🙂

Автоматическая проверка пакета

Существует утилита lintian, позволяющая проверить пакет и выявить типичные ошибки в его структуре. Делается это так:
$ lintian supersh_1.0-1_all.deb

Установка пакета

Создаём собственный репозиторий пакетов

Теперь у нас есть собственный пакет. Когда их будет несколько, и тем более — с зависимостями, окажется, что намного удобнее быстренько поднять собственный локальный микро-репозиторий, и включить его в список источников менеджера пакетов 🙂 Здесь я опишу быстрый HowTo «как создать свой репозиторий». Идею будет легко развить, почитывая соответствующую документацию 🙂
Сперва установим помощника:
$ sudo apt-get install reprepro

Описание будущего репозитория

Центр репозитория — его описание. Главное в нём — список компонент репозитория. Мы создадим компоненты «soft» и «games».
Выберите папку для будущего репозитория. Все действия производятся из её корня.
Создаём файл conf/distributions следующего содержания:
Description: my local repository
Origin: Ubuntu
Suite: testing
AlsoAcceptFor: unstable experimental
Codename: karmic
Version: 5.0
Architectures: i386 amd64 source
Components: soft games
UDebComponents: soft games

В нашем деле создания простого репозитория все поля не играют принципиальной роли, и используются лишь для визуального определения «что есть что» 🙂

Создание репозитория

Репозиторий описан! Теперь сгенерируем болванку на основе описания. Команды выполняются в корне репозитория:
$ reprepro export
$ reprepro createsymlinks
И добавим готовый репозиторий в /etc/apt/sources.list:
deb file:///path/to/repo/ karmic soft games
Этот репозиторий можно также расшарить при помощи веб-сервера.

Управление пакетами в репозитории

Финиш

UPD: @ICD2 подсказывает, что есть GUIшная прога для создания пакетов: GiftWrap.

Еще раз о deb пакетах

Подготовка

Чтобы начать создавать deb пакеты, нужно установить несколько пакетов:

Подготовка папки с исходниками

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

Папка должна называться имяпакета-версия. Т.е. если у меня есть папка Plugins с программой версии 0.1, то я создаю папку с именем plugins-0.1.

Теперь нужно создать архив с этой папкой. Архив должен содержать в имени *.orig.tar.gz, т.е.:

Последний подготовительный шаг, это создание в папке с исходниками папки debian со множеством служебных файлов. Чтобы это сделать, нужно выполнить команду:

В процессе выполнения этой команды будет задан вопрос о том, какой тип архива мы создаем, самый простой это single.

Настройка пакета

Вся настройка пакета происходит путем редактирования файлов в каталоге debian. Рассмотрим те файлы, которые будем использовать:

changelog

Данный файл содержит историю изменения пакета и текущую версию пакета. Посмотрим на его содержимое:

В начале идет название пакета — libvksplugins, затем его версия. Версия делиться на две части символом «-». Первая часть показывает версию программы в пакете, вторая «ревизию» пакета. Ревизия это версия пакета, т.е. если раньше такого пакета не было, то ревизия равна 1. Если же пакет с такой версией программы уже был, но в нем произошли изменения, то ревизия увеличивается.

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

Надпись urgency=low показывает срочность изменения. Т.к. срочности нет, то значение равно low. Если бы, мы делали пакет для исправления серьезной уязвимости или ошибки, то значение можно было бы установить в high.

После первой строки идет пустая строка, а за ней первая запись:

В Debian, changelog используется для автоматического закрытия ошибок в системах отслеживания ошибок в программных продуктах. Т.к. в данном случае, я не использую такую систему, то эта строка принимает вид:

Последняя строка является подписью человека, сделавшего запись. В ней содержится имя и адрес, а также дата изменения.

После установки deb пакета, файл changelog устанавливается в

control

Файл debian/control является главным конфигом, при создании deb пакета. Вот пример такого файла:

Видно, что файл разбит на секции при помощи пустых строк. Каждая секция описывает один пакет, создаваемый из папки с исходниками. Рассмотрим их по порядку:

Source Данная секция говорит о том, что нужно создать пакет исходных кодов. Параметром указано libvksplugins, это значит, что пакет исходных кодов будет называться libvksplugins.

Priority Эта секция устанавливает приоритет пакета. Т.к. система может прекрасно обойтись без нового пакета, то значение секции установлено в optional. Т.е. этот пакет не обязателен для установки. Подробнее о приоритетах написано здесь.

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

Build-Depends Одна из самых важных секций, устанавливающая зависимости пакета. Зависимости, указанные в данной секции должны быть выполнены, чтобы можно было собрать пакет. Т.е. список зависимостей для сборки и установки могут отличаться.

Видно, что в зависимостях стоят debhelper (>= 9), cmake. Зависимость debhelper (>= 9) ставиться для всех пакетов по умолчанию. Она нужна для корректной работы программ вида dh_*.

Второй элемент cmake был добавлен потому, что папка с исходниками содержала файл CMakeLists.txt, т.е. для сборки используется система сборки CMake. Для того, чтобы узнать, какие зависимости есть у программы, можно почитать ее документацию. Кроме этого, можно воспользоваться командой dpkg-depcheck. Данная команда должна запускаться так:

Но, т.к. при использовании CMake нет скрипта конфигурирования, то я использую ее так:

Из примечательных тут можно отметить:

cmake
qt4-qmake
libqt4-dev

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

При этом в CMakeLists.txt указана версия cmake, которую нужно использовать:

Я думаю, что разработчику виднее, и поэтому указываю версию из CMakeLists.txt. Для Qt 4 все понятно с номерами версий, но для очистки совести проверим и их версии:

Т.е. для Qt 4 указываем версию 4.8.6:

Standards-Version Версия стандарта, в соответствии с которым создан файл. Это значение не нужно менять.

Section. Секция для пакета, т.е. группа пакетов, выполняющая одну задачу. В Политике Debian разделе 2.4 этот вопрос описан более подробно.

Homepage Домашняя страница проекта. Т.к. данный код писал я и у него нет страницы, просто удаляю эту строку.

Vcs-* Ссылки на репозитории проекта. Их у меня тоже нет, поэтому удаляю эти строки.

Другие пакеты После секции файла, где описывается пакет с исходниками, идут секции, которые описывают другие пакеты, создаваемые из пакета с исходниками. Схема создания пакетов:

Из схемы видно, что из исходников программы, я хочу получить 4 пакета:

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

Кроме описанных выше пакетов, можно создать dbg пакет с отладочной сборкой программы. Это может пригодиться, если программа падает и у Вас есть под рукой отладчик. Однако, я так и не смог понять как это делать. Документация не дает ответа на этот вопрос. Если делать так как описано в ней, то я либо получаю пустой пакет либо получаю кучу ошибок при сборке.

Схема на рисунке выше показывает, что пакет с исходниками называется libvksplugins_source, однако, в файле control указано, что пакет с исходниками будет называться libvksplugins. На самом деле, он действительно будет называться libvksplugins, а пакет с бинарниками, будет называться libvksplugins… deb. Суть этой путаницы в том, что пакет с исходниками представляет собой tar архив и служебные файлы, тогда как пакет бинарников это архив с расширение deb.

Настройка пакета библиотеки Посмотрим внимательно на описание пакета библиотеки:

Для пакетов, содержащих скрипты или тексты, нужно указывать значение как all.

Третья строка, описывает зависимости создаваемого пакета. Вот как она описана в 4й главе Руководства начинающего разработчика Debian:

Т.е. эта строка говорит о том, что сборщик пакета сам определит зависимости.

Последний раздел данной секции это описание пакета. Первая строка содержит кратное описание, последующие строки содержат более подробное описание. Подробное описание, должно иметь определенный формат:

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

rules

Данный файл является аналогом Makefile для сборки пакетов. По умолчанию, он создается в таком виде:

Видно, что это bash скрипт с синтаксисом Makefile. Единственная интересная конструкция здесь это

Т.к. исходники используют систему сборки CMake, то нужно изменить эту запись следующим образом:

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

После того, как мы указали в debian/control какие пакеты мы хотим получить, нужно указать какие файлы в какой пакет помещать. Для этого, для каждого названия пакета из файла control, нужно создать в папке debian два файла. Первый должен называться пакет.dirs, а второй пакет.install. Суть файлов в том, что первый указывает, какие папки нужно создать для пакета, а второй, какие файлы включить в пакет.

Посмотрим на их содержимое:

Важный момент, отсутствие начальной дроби в путях и отсутствие дроби в конце пути к папке. Проверив, куда CMake устанавливает файлы библиотеки, можно сформировать такие файлы:

Завершение настройки

Т.к. исходники мои, то никаких дополнительных описаний и ограничений copyright у меня нет, поэтому я удаляю все лишние файлы из каталога debian.

Сборка пакетов

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

Заключение

Если вы дочитали до сюда — значит вы любите читать.

Этот текст является результатом моего опыта внедрения deb пакетов на работе. Опыт показал, что наличие сетевого репозитория (reprepro) и внимательное отслеживание версий, позволяют без проблем обновлять и тестировать различные версии ПО на парке из 30 машин с системами Astra Linux 1.3, 1.4 и Эльбрус ОС.

There is some new and interesting documentation on packaging:

If you need to create rapidly a package, use equivs.

If you prefer to gain real knowledge about Debian packaging:

Then read the interesting PDF file included in the package: packaging-tutorial

This is a pragmatic approach to learning how to create Debian packages.

If the information below doesn’t answer your questions, please look in the New Maintainer’s Guide and in Debian Policy

The Debian package management chapter of the Developers Reference contains lots of useful information for handling all kinds of problems one runs into with apt and dpkg.

If you want to create an official Debian package, make sure it’s not already packaged.

If somebody is working on the package, you should contact them if you intend to make an official package together.

For a slightly more modern way of managing all of this, check out git-buildpackage. TODO: write this page around git-buildpackage, instead of quilt, for a less baroque and more familiar experience.

Initial compilation

Before starting there are some risks you should be aware of:

WARNINGS:

All these operations are preferably done in a chroot environment for safety/security reasons. pbuilder and sbuild are such environments. Please consult the pbuilder or sbuild documentation.

running make on a system can be a security risk! It is recommended to check beforehand that the Makefile does not contain any funny stuff. Obscure/specially crafted applications might fall into this case.

do NOT run make install, unless you are absolutely sure is safe to do that (check the install target of the makefile). This is a security risk and you may risk to break and/or compromise your system.

the package is not being worked on (ITP (Intent To Package) is pending)

are you sure it’s not packaged? You could check other Debian based distributions, too.

It is best to create a chroot jail in which to build the application. This mitigates security and system corruption problems. In addition it ensures that any local changes to your machine will not interfere with the build.

»Debianization»

After the first compilation, it’s time to create the Debian specific part of the package.

Debianize the package by using dh_make or one of the other automatic packaging tools.

File debian/control: Add to the Build-Depends (sometimes even Build-Depends-Indep) the list of packages needed to be installed for the application to compile (remember the list done previously). You should leave out any packages that are listed in /usr/share/build-essential/essential-packages-list or /usr/share/build-essential/list and also leave out any packages that listed as dependencies by any of those packages.

Review each of the template files (debian/*.ex). If your package needs that feature, then customize the file as needed and rename it without the «.ex».

Make sure that all the directories you will place files in are listed in the debian/dirs file without a leading slash (/).

Make sure that the files are installed in the proper place (under a directory, not on the root system). Take care at the install target from the application makefile. If the application uses autoconf and automake, it may be enough to set the environment variable DESTDIR, e.g. «make DESTDIR=$(CURDIR)/debian/packagename». (dh_make will set this up automatically.)

Note: very often the upstream package will install files under /usr/local. DO NOT INSTALL ANY FILES IN THERE.

Initial compilation of the package

Building Debian packages

To make sure that a Debian package meets all build dependencies and is not influenced by anything specific to the user’s environment, packages should be built in a chroot environment. Tools like pbuilder can be used for this.

When working on a package, a faster rebuild can be done with ‘debuild’. But then, all build-dependencies must be satisfied in the installation where the package is built. All necessary packages can be installed automatically with apt-get build-dep. A complete example for building the foo package looks like this: A very basic introduction to create an empty package or a package with just a pdf file (sentence fragment added by HenriLeFoll in Rev. 76)

This is usually enough for you to backport packages.

Testing and Check the package

All tests in chroot

Testing the package

Lintian

Test all the packages with lintian.

Piuparts

Check points for any package

If there are architecture independent things in the package and if they are big enough, are those packaged in a separate package with arch all?

This list of checks is deprecated as check-all-the-things replaces it, except for a couple of checks documented in the TODO file.

Other ideas can be taken from the check-build script in the pkg-perl-tools package.

This page is still incomplete; please help by adding information to it. Do not forget that the information here should be in a concise form.

Examples

There are interesting examples in the PDF file included in the package : packaging-tutorial.

• ← Crazy frog how do you do
• Create yourself перевод на русский →