Еще раз о 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 и Эльбрус ОС.
Воззрения кота Manual’а. Deb-пакеты. Часть 1. Пакеты
Изложение воззрений кота Manual’а на те аспекты работы с deb-пакетами, которые влияют на индивидуализацию системы. И первая их часть будет посвящена общим вопросам. В ней будет говориться о пакетах вообще и deb-пакетах в особенности. Читатель, знакомый с этими понятиями, может спокойно её пропустить.
Пакеты, зависимости, библиотеки
Пакеты — это своего рода программные кванты, на которые делится система или дистрибутив. Это могут быть и простые монофункциональные утилиты (например, строчный текстовый редактор ed или архиватор tar ), более или менее обширные наборы функционально связанных программ (скажем, coreutils) или составные части огромных программных комплексов (примером чему — рабочая среда Cinnamon, которая будет предметом специального рассмотрения).
Термин пакет (английское package) употребляется в двух смыслах: как авторский набор исходных текстов, созданный разработчиком программы, и как комплект скомпилированных из него исполняемых программ и всех их служебных файлов, собранный майнтайнерами дистрибутива или вообще третьими лицами. Пакеты в первом смысле называются исходниками или вообще «сырцами» (от английского Source), во втором — бинарниками. В этом manual’е речь пойдёт почти исключительно о пакетах во втором понимании этого термина.
Бинарные пакеты специфичны для семейств некогда родственных дистрибутивов, почему часто говорят о системах rpm based или deb based. Но даже если они собраны в одном формате (например, rpm или deb), бинарные пакеты из разных дистрибутивов далеко не всегда совместимы в рамках одной системы. Впрочем, к формату deb, который здесь рассматривается, это относится в наименьшей степени: например, пакеты для всех дистрибутивов семейства Ubuntu сохраняютпочти полную бинарную совместимость внутри него, а иногда — с пакетами прародительского Debian’а и его прямых клонов.
Ключевым для бинарных, или дистрибутивных, пакетов является понятие зависимостей. Суть его в том, что пакет packagename1 для сборки, установки и (или) функционирования требует наличия в системе пакета packagename2, тот, в свою очередь, может потребовать пакета packagename3, и так далее.
«Мягкие» зависимости данного пакета не критичны для его функционирования — удовлетворение их лишь добавляет ему дополнительные функции (например, печати и сканирования для офисных и графических приложений) или возможности (скажем, доступ к файлам данных определённых форматов для той же графики или мультимедиа).
В deb-формате бинарных пакетов предусмотрено более дробное разделение «мягких» зависимостей, но об этом подробнее будет говориться чуть позже. А пока замечу, что часто приходится учитывать и так называемые конфликтующие зависимости — то есть альтернативные по назначению пакеты, не способные ужиться в одной системе.
Понятие зависимостей пронизывает насквозь UNIX-совместимые системы, и особенно важно для свободных их представителей. Ибо традиционная модель разработки UNIX-программ (то, что задумчиво именуют UNIX Way) характеризуется ярко выраженным стремлением не множить сущности без крайней необходимости. Или, говоря попросту, не изобретать велосипеды. Ведь все программы, вне зависимости от их назначения, неизбежно должны выполнять некоторые однотипные действия, как то: открыть файл, записать его, вывести на экран его содержимое, и так далее. Сущность таких действий не меняется, что бы программа ни делала. И потому нет никакого смысла программировать такие манипуляции каждый раз заново.
Вот их, как правило, поддаваясь смертному греху лености, и не программируют «с нуля». А объединяют соответствующие директивы в отдельные программные комплексы, именуемые библиотеками (libraries). Сами по себе они к автономному исполнению не предназначены. Однако любая программа, при необходимости совершить одно из типовых действий, вызывает из такой библиотеки некий фрагмент кода, содержащий требуемую последовательность директив.
Однако главной системной библиотекой список не исчерпывается. В UNIX-подобных системах при создании пользовательских интерфейсов используются библиотеки свойств терминала (например, ncurces ) для консольных программ и библиотеки, описывающие процедуры отрисовки окон и управления ими — для графических программ системы X, библиотеки интерфейсных элементов и графических примитивов более высокого уровня (Motif, Qt, Gtk), библиотеки описания графических и мультимедийных форматов файлов и тому подобные «сборники». Иными словами, существует тенденция к вынесению в разделяемые библиотеки всех повторяющихся действий и элементов, какие только возможно.
Если библиотек, используемых в программах для консольного режима, не так много, они достаточно универсальны и легко поддаются учёту, то с библиотеками для обеспечения графического режима существенно сложнее. Даже простое перечисление их заняло бы немало места. Поэтому ограничусь упоминанием главных из них, на которых базируются рабочие среды (они же именуются десктопами, DE) и их штатные приложения.
Большая часть распространённых десктопов использует библиоотеки Gtk 3-й и, реже, 2-й верси. В их числе Cinnamon, LXDE, MATE, Xfce, Unity и, наконец, GNOME 3 (далее именуемый просто GNOME, поскольку вторая ветка этой среды вымерла соответственно. К ним же примыкает). Последний десктоп для своей работы требует также собственных библиотек GNOMElibc.
На библиотеке Qt основана среда KDE, которая также не живёт без собственных библиотек из набора KDELibs. Чистая Qt используется в настоящее время только в десктопе LXQt. Однако в будущем ожидается переход на эту библиотеку десктопа Budgie. Также на Qt основана среда Unity 8, в том числе и её десктопный вариант, который, правда, пока назвать работоспособным язык не поворачивается.
Надо заметить, что в последнее время возник и другой подход к разрешению запивсимостей: упаковка исполняемых модулей программ вместе со всеми необходимыми для их работы библиотеками в единый, самодостаточный пакет. Таковы системы Snap (изначально созданныая для Ubuntu, но ныне способная работать и в более иных дистрибутивах) и от рождения кросс-дистрибутивная система Flatpak. Однако ни та, ни другая всенародного признания пока не получили, так что речи о них в этом Manual’е не будет.
Формат deb-пакетов
Формат пакетов deb был разработан ещё в прошлом тысячелетии для дистрибутива Debian и унаследован от него Ubuntu, во многом предопределив успех последней. А вслед за ней — и удачливость многих её клонов. Почему deb-формату и следует уделить некоторое внимание.
Зависимости в терминах deb-пакетов имеют несколько градаций: обязательные ( depends ), рекомендуемые ( recommends ), предлагаемые ( suggests ), конфликтующие ( conflicts ). Первая градация — это обычные «жёсткие» зависимости, без удовлетворения которых пакет либо не будет работать, либо вообще не установится. С градацией последней тоже понятно — это, так сказать, анти-зависимости.
Ну а зависимости рекомендуемые и предлагаемые — это две разновидности «мягких» зависимостей. Разница между ними в том, что рекомендуемые пакеты обеспечивают «зависимому» пакету дополнительные функции (например, поддержку мыши в консольных приложениях), а пакеты предлагаемые предоставляют дополнительные возможности, вполне вероятно, полезные, но не жизненно необходимые (например, документацию, в том числе на не-английских языках).
То есть первая категория «мягких» зависимостей как бы более нужная, нежели вторая. Впрочем, таково субъективное мнение майнтайнера конкретного пакета — вполне возможно, что у применителя будет по этому поводу мнение более иное. И потому и пакетный менеджер apt, и его графическая «морда» Synaptic, устанавливающие зависимости автоматически, в в большинстве deb based дистрибутивов по умолчанию не делают этого ни для рекомендуемых, ни, тем более, для предлагаемых пакетов, а лишь выводят их список, дабы применитель сам принял решение по данному вопросу.
Кроме зависимостей, для пакетов deb-формата важно также понятие их приоритета. Оно отражает степень необходимости пакета для функционирования системы, например: обязательный ( required ), без которого работа системы невозможна, основной ( base ) и важный ( important ), также оказывающиеся практически необходимыми, стандартный, то есть имеющийся практически в любой полнофункциональной Linux-системе, дополнительный ( optional ) — тут уж степень важности каждый должен решать для себя.
Первый — самый обычный тарбалл исходных текстов авторского пакета, что подчеркивается словом orig в его имени: формат архива, имя и система нумерации версий также совпадают с таковыми авторского пакета. Файл packagename.dsc содержит в себе всю метаинформацию, необходимую для правильного построения из него бинарного deb-пакета. А packagename.diff.gz — это те изменения исходного кода, которые вносятся для адаптации пакета непосредственно к данному дистрибутиву. Если таких изменений не потребовалось (или если пакет писался именно для данного дистрибутива), он может и отсутствовать.
Статус пакетов
В системах пакетного менеджмента deb based дистрибутивов, в том числе и в Mint, пакеты объединяются в категории, секции и группы. Список категорий включает следующие пункты:
В секции пакеты группируются по назначению: программы для администрирования, базовые пакеты, текстовые редакторы, и так далее.
Каждый пакет в терминологии имеет основной статус, обозначаемый строчной литерой; в их число входят:
i (от install) — установленный пакет;
p (от purge) — пакет не установленный или деинсталлированный «вчистую» (то есть с удалением его конфигурационных файлов);
c (от clean) — пакет, деинсталлированный с сохранением конфигурационных файлов;
v (от virtual) — виртуальный пакет.
Кроме того, пакеты могут иметь один из следующих дополнительных статусов, хотя это и не обязательно:
Обращаю особое внимание на пакеты, имеющие статус A : они устанавливаются вместе со своими зависимостями и могут быть удалены только вместе с ними. Правда, как мы увидим дальше, статус установленного пакета может быть изменён, и тогда он станет доступным для индивидуального удаления.
Средства для работы с пакетами
Инструментарий для работы с пакетами можно разделить на пять групп:
Оболочки для установщиков пакетов выполняют те же самые функции, что и они сами, посредством как прямых команд (утилита gdebi ), так и средствами графического интерфейса. К числу последних принадлежат Gdebi (использующая Gtk), Gdebi-kde (для одноимённой среды), Qapt, основанная на библиотеке Qt. Сдежует заметить, что все эти оболочки не только отслеживают выполнение или нарушение зависимостей, но и предпринимают попытки их разрешения, более или менее успешные, в зависимости от обстоятельств.
Четвёртая группа — графические фронт-энды для менеджеров пакетов. Нынче она представлена программой Synaptic; её аналог для среды KDE, Muon, назвать вполне функциональной нельзя.
Что же касается пятой группы — это самые высокоуровневые программы, в которых прозрачно для применителя интегрированы функции поиска пакетов в Сети, подключения к содержащим их репозиториями и собственно пакетный менеджмент. Название её заимствовано от Центра приложений Ubuntu — первого представителя этой группы. Хотя в некоторых случаях программы этой группы могут оказаться полезными, автору этих строк они представляются избыточными, и речи о них в данном Manual’е не будет. Остальные же инструменты работы с пакетами будут рассмотрены в его следующих частях.
1 комментарий к “ Воззрения кота Manual’а. Deb-пакеты. Часть 1. Пакеты ”
Оставьте комментарий Отменить ответ
Для отправки комментария вам необходимо авторизоваться.
Введение
Несмотря на то что большинство пакетов создается с использованием debhelper, понимание того как устроен deb-пакет «изнутри» даст возможность разобраться зачем нужна та или иная утилита dh_ или что делать когда возникает задача создать «нестандартный» src-пакет итд. Лишние знания, как известно не отягощают голову, а, напротив, облегчают ей работу когда перед ней наконец появляется задача, требующая решения 
Что представляет собой deb-пакет?
Deb-пакет это обычный архив файлов, содержащий файлы, предназначенные для установки в систему, а так же некоторые служебные файлы, необходимые для того чтобы эту установку сделать гибкой. При помощи программы ar упаковано в один файл:
Архив control.tar.gz, содержащий скрипты, написанные майнтенером пакета, использующиеся при установке/удалении пакета, а так же другие служебные файлы;
Архив data.tar.gz, содержащий двоичные файлы программы, ради которой создан пакет;
Поскольку содержимое пакета может в будущем измениться (будет новый номер версии в debian-binary), то собирать deb-пакет при помощи программ tar, gzip, ar не рекомендуется и этот вариант в статье рассматриваться не будет.
Файлы и каталоги, предназначенные для установки в систему. Их расположение в архиве соответствует положению их в файловой системе если считать от корня. Например файл usr/share/doc/package/copyright в deb-архиве после установки будет находиться в /usr/share/doc/package/copyright (все они будут упакованы в архив data.tar.gz);
Каталог DEBIAN/, содержащий служебную информацию о пакете (о ней пойдет речь ниже). Содержимое этого каталога при сборке будет упаковано в архив control.tar.gz;
Низкоуровневые функции работы с deb-пакетом
Программа dpkg
Представляет наиболее низкоуровневый интерфейс для создания/установки/распаковки пакетов.
при этом из каталог Directory будет упакован в пакет.
То есть все что нам нужно чтобы создать пакет для Debian, это сложить файлы в нужные директории и упаковать. Фактически это почти тоже самое что и простой архив tgz дистрибутива slackware, только информационные файлы располагаются в каталоге с другим именем и видов этих файлов несколько больше.
Ну а теперь, когда мы уяснили базовое устройство пакета, можем перейти к описанию того что должно или может находиться внутри каталога DEBIAN/.
Обязательное содержимое DEBIAN/
Файл control
и некоторые другие параметры.
Короткое описание содержимого этого файла на русском языке Вы можете найти здесь, а полное описание на английском языке в Debian-policy. Смотрите так же man deb-control.
Необходимо отметить: в src-пакетах как правило лежит файл debian/control, который является лишь шаблоном для того файла contol, который будет упакован в deb-пакет. Скрипты сборки пакета добавят несколько полей в этот шаблон, вычислят зависимости от библиотек, проставят версию пакета (взяв ее из changelog), разобьют общий control нескольких пакетов на несколько control-файлов, если из одного src-пакета производится сборка нескольких deb-пакетов.
Опциональное содержимое DEBIAN/
Файл md5sums
Содержит md5 хеши для всех файлов кроме файлов находящихся в каталоге DEBIAN/. Данный файл необязателен для deb-пакета, однако программы верификации пакетов считают пакеты, несодержащие этот файл ошибочными. Может использоваться некоторыми программами администрирования системы для верификации изменений в файловой системе.
Скрипты для установки/удаления пакета
Пакет может содержать несколько скриптов (или программ), которые будут вызываться при установке/удалении пакета. Эти скрипты позволяют майнтенеру выполнять некоторые действия при установке/удалении. Например этими скриптами могут создаваться/удаляться каталоги в которых программа будет хранить свои временные данные, может производиться добавление/удаление программы в меню вашего оконного менеджера, первичное конфигурирование программы и так далее.
Соответственно порядок вызова скриптов и опции их вызова может быть разный. Скрипты могут вызываться со следующими параметрами (полный перечень можно найти в Debian-policy):
Параметр
Доп-параметры
Описание
preinst
Вызывается перед распаковкой пакета. Номер версии указывает на пакет, который стоял ранее, но был удален без ключа —purge, то есть конфигурационные файлы сохранены. С данным параметром скрипт вызывается если в системе пакет не установлен.
Вызывается перед распаковкой пакета. Номер версии указывает на пакет, который стоял ранее. Выполняется upgrade или downgrade для пакета. Зная текущую версию пакета и сравнив её с передаваемым здесь значением мы можем определить что происходит upgrade или downgrade
Вызывается если preinst upgrade вызванное для нового пакета завершилось неудачей. Номер версии соответствует номеру версии нового пакета, который пытались установить. Таким вызовом установленный пакет информируется о том что его попытались неудачно проапгрейдить.
postinst
Вызывается после распаковки пакета. Номер версии содержит версию пакета корректно сконфигурированного ранее. То есть того для которого данный вызов завершился без ошибки. По номеру версии скрипт конфигурации может принять решение о том каким образом необходимо производить апгрейд конфигурационных файлов программы
Вызывается системой Debconf после переконфигурации пакета. Выполняет все необходимые действия по переконфигурации.
Вызывается если preinstall upgrade нового пакета завершился неудачей. Новый пакет не устанавливается, а старый при этом может провести собственную переконфигурацию для того чтобы сохранить работоспособность.
prerm
Вызывается перед удалением пакета.
Вызывается перед удалением пакета при его апгрейде. Номер версии указывает на версию устанавливаемого пакета.
Вызывается для устанавливаемого пакета, если prerm upgrade удаляемого пакета завершился с кодом ошибки. Номер версии указывает на удаляемый пакет
postrm
Вызывается после удаления пакета
Вызывается после удаления пакета при его апгрейде. Номер версии указывает на новый пакет.
Вызывается после удаления пакета при его апгрейде. Вызывается в случае если postrm upgrade вернул код ошибки. Номер версии указывает на удаляемый пакет. Вызов скрипта происходит во вновь устанавливаемом пакете.
Вызывается если preinst install вернул код ошибки. Номер версии соответствует номеру версии передаваемому preinst install
config
Вызывается во время предварительной настройки пакета из dpkg-preconfigure. Этот вызов проходит во время установки/апгрейда пакета. Номер версии указывает на версию установленного на данный момент пакета.
* Необязательный параметр
Файл templates
Если используется возможность конфигурации/реконфигурации пакета в системе Debconf (скрипт config), то этот файл содержит шаблоны диалогов с пользователем.
Файл conffiles
Содержит перечень файлов пакета, которые являются конфигурационными. По одному файлу на одну строку. Эти файлы при апгрейдах пакета заменяться не будут (или же будут задаваться вопросы с предложением о замене). Подробнее о содержимом см. man debconf-devel
Утилиты для работы/генерации содержимого DEBIAN/
Утилита dpkg-gencontrol
Осуществляет генерацию файла control на базе шаблона этого файла, составляемого майнтенером, а так же дополнительных параметров, передаваемых из командной строки. В частности, устанавливает номер версии пакета, архитектуру итп. Номер версии обычно берется из файла changelog, однако иногда бывает необходимо из одного src-пакета собрать несколько deb-пакетов с разными номерами версий. Опция -v поможет Вам в этом.
Утилита dpkg-shlibdeps
Вычисляет зависимости для исполняемых файлов и библиотек. Майнтенер обычно указывает Build-зависимости (зависимости сборки), а Depend-зависимости (зависимости необходимые для работы) вычисляются с помощью этой (или подобных) утилит. Такой подход дает возможность не привлекать майнтенера при смене имен библиотек от которых зависит пакет.
Утилита dpkg-parsechangelog
Позволяет извлекать из changelog-файла некоторые параметры, вроде номера версии, координат и имени майнтенера итп. Результаты работы этой утилиты могут использоваться как входные параметры для утилит вроде dpkg-gencontrol.
Утилита dpkg-architecture
Позволяет извлекать информацию (манипулировать ей) об архитектуре системы для которой собирается пакет или на которой собирается пакет. Выходные данные так же могут использоваться для использования в других утилитах. Например при генерации файла control утилитой dpkg-gencontrol.
Проверка соответствия пакета современным требованиям Debian
После того как пакет создан, можно получить информацию о его содержимом с помощью вышеупомянутой утилиты dpkg.
После этих двух проверок (все файлы на месте, информация в финальном control корректна), можно запустить одну из двух проверки пакета на соответствие текущему полиси.
покажет подробную информацию о проблемах в пакете.
