Просмотр кода страницы Как собрать бинарный deb пакет: подробное HowTo

Сегодня я расскажу на абстрактном примере как <u>правильно</u> создать *.deb пакет для Ubuntu/Debian. Пакет мы будем делать бинарный. Пакеты, компилирующие бинарники из исходников здесь не рассматриваются: осилив изложенные ниже знания, в дальнейшем по готовым примерам можно понять суть и действовать по аналогии :)<br>
<br>
В статье не будет никакой лишней возни «вручную»: формат пакета эволюционировал в достаточно простую, а главное — логичную структуру, и всё делается буквально на коленке, с применением пары специализированных утилит.<br>
<br>
В качестве бонуса в конце статьи будет пример быстрого создания собственного локального репозитория: установка пакетов из репозитория позволяет автоматически отслеживать зависимости, и конечно же! — устанавливать всё одной консольной командой на нескольких машинах :)<br>
<br>
Для тех, кто не хочет вдаваться в мощную систему установки софта в Linux, рекомендую посетить [http://www.asic-linux.com.mx/~izto/checkinstall сайт проги CheckInstall]: она автоматически создаёт deb-пакет из команды «make install» ;) А мы вместе с любопытными — <br>
<br>
<h4>Источники</h4><br>
Информация надёргана из многих мест, но вот два основных:<br>
<ul>
<li>Opennet:L [http://www.opennet.ru/docs/RUS/debian_pkg/deb.html Введение в создание пакетов для дистрибутива GNU Debian/Linux]</li>
<li>Debian.org: [http://www.debian.org/doc/debian-policy/ Debian Policy Manual] — официальная</li>
<li>Ubuntu Wiki: [https://wiki.ubuntu.com/PackagingGuide/Basic?action=show&amp;redirect=HowToBuildDebianPackagesFromScratch/ PackagingGuide/Basic]</li>
</ul><br>
В статье подробно изложены основы создания пакетов, достаточные для получения достаточно мощного управления установкой приложений. Более продвинутые фичи опущены, но предложены прямые ссылки на документацию для интересующихся.<br>
Статья не является копией или переводом какой-либо документации: это — коллекция знаний, валявшихся в виде заметок, а теперь оформленная в виде статьи. Для ясности везде есть примеры, разъяснения на пальцах, найденные мной удобные фичи и некоторые типичные ошибки, которые можно совершить по незнанию.<br>
<br>
<h4>Подготовка</h4><br>
<br>
<h5>Зачем это всё?</h5><br>
Да, CheckInstall умеет создавать рабочий пакет, но он не поддерживает все вкусности, на которые способны deb пакеты :) А именно:<br>
<ul>
<li>Скрипты, выполняющиеся до, после <s>и вместо</s> установки пакета :)</li>
<li>Автоматическое управление конфигурационными файлами: пакет не позволит затереть старые конфиги новыми без спроса</li>
<li>Работа с шаблонами: возможность задавать пользователю вопросы при установке (!!!)</li>
<li>Изменение файлов других пакетов</li>
</ul><br>
<br>
<h5>Что потребуется</h5><br>
Конечно, для создания полноценного пакета хватит архиваторов tar, gz, ar, но можно исключить лишнюю возню, и воспользоваться инструментами, созданными для облегчения жизни :)<br>
Ставим:<br>
<code>$ sudo apt-get install dpkg debconf debhelper lintian </code><br>
<br>
<h5>Что мы будем делать</h5><br>
Для примера будет рассмотрен некий скрипт /usr/bin/super.sh. Не важно что внутри, главное — как он появится на правильном месте :)<br>
<br>
<h5>Подготовка папки</h5><br>
В домашнем каталоге (или где удобно) создаём папку, в которой будут лежать все файлы будущего пакета: <code>mkdir ~/supersh</code>. Далее будем называть её <b>корень пакета</b>.<br>
В корне пакета создаём папку «DEBIAN» (заглавными буквами, это важно!). Эта папка содержит управляющую генерацией пакета информацию, и не копируется на диск при установке пакета.<br>
Также корневая папка пакета содержит будущий «корень диска»: при установке пакета все файлы (кроме папки «debian») распаковываются в корень /. поэтому наш скрипт должен лежать по такому пути, относительно корня пакета: «usr/bin/super.sh»<br>
Белым по чёрному:<br>
<code>mkdir -p ~/supersh/DEBIAN # управляющая папка<br>
mkdir -p ~/supersh/usr/bin # путь к скрипту<br>
cp super.sh ~/supersh/usr/bin/ # копируем наш скрипт в нужное место</code><br>
В итоге имеем:<br>
<code>supersh/DEBIAN/<br>
supersh/usr/<br>
supersh/usr/bin/<br>
supersh/usr/bin/super.sh<br>
</code><br>
<br>
<h4>Создание пакета: DEBIAN/*</h4><br>
Как я уже сказал, папка DEBIAN содержит файлы, используемые при установке. Здесь я опишу (с примерами) каждый файл.<br>
Для создания полноценного пакета достаточно контрольного файла «control», все остальные используются либо для прикрепления текстовой информации (changelog, лицензия), либо для управления расширенными возможностями установки приложений.<br>
Из описанных ниже файлов в папке DEBIAN/* выбираем необходимые, и заполняем согласно инструкции :)<br>
В наше примере реально используется только <b>обязательный DEBIAN/control</b>.<br>
<br>
<h5>DEBIAN/control: Основная информация</h5><br>
control — центральный файл пакета, описывающего все основные свойства. Файл — текстовый, состоящий из пар «Атрибут: значение». Можно использовать комментарии: символ "#" в начале строки (возможность была добавлена в версии dpkg &gt;= 1.10.11, надеяться на комментарии не стоит :).<br>
В таблице приведены все поля, определённые для контрольного файла. Обязательные поля выделены <b>жирным</b>: без них пакет не будет считаться составленным верно.<br>
<table>
<tbody><tr>
<th>Атрибут</th>
<th>Описание</th>
<th>Примеры</th>
</tr>
<tr>
<th colspan="3"> — основные — </th>
</tr>
<tr>
<td><b>Package:</b></td>
<td>Имя пакета: [a-zA-Z0-9-] — только латиница, цифры, и дефис. Имя используется при установке: apt-get install &lt;package&gt;</td>
<td><code>Package: supersh</code></td>
</tr>
<tr>
<td><b>Version:</b></td>
<td>Версия пакета (и проги внутри). Используется для определения «обновлять ли». <br>
Формат принят такой: <code>&lt;версия_программы&gt;-&lt;версия_пакета&gt;</code>. <br>
Рекомендую <b>всегда</b> указывать версию пакета: при изменении структуры пакета цифра увеличивается на единичку. <br>
Допустимые символы достаточно вольные: можно использовать дату и буквы. Примеры смотрите сегодня в своём репозитории :)</td>
<td><code>Version: 1.0-1&lt;br&gt;Version: 2009.12.12-1</code></td>
</tr>
<tr>
<td>Provides</td>
<td>Имя приложения (возможно, виртуальное), регистрируемое в системе в результате установки этого пакета. <br>
Используется редко: в основном, если нужно изменить имя пакета, или если более одного пакета предлагают одинаковый функционал. Например, пакеты Apache и nginx предоставляют возможность демона httpd: <code>Provides: httpd</code><br>
Вы наверняка сталкивались с ошибкой при попытке установки: «is a virtual package». Это оно и есть :)</td>
<td><code>Provides: supersh</code></td>
</tr>
<tr>
<td><b>Maintainer</b></td>
<td>Имя и почта мэйнтейнера пакета: человека, который «дебианизировал» приложение. <br>
Формат произвольный, но принято <code>имя &lt;e-mail&gt;</code></td>
<td><code>Maintainer: o_O Tync &lt;o-o-tync.habrahabr.ru&gt;</code></td>
</tr>
<tr>
<td><b>Architecture</b></td>
<td>Архитектура процессора, для которой предназначен пакет.<br>
Допустимые значения: <code>i386, amd64, all, source</code><br>
<code>all</code> используется для скриптов: они же портативные, верно? :)<br>
<code>source</code> используется для компилируемых пакетов с исходниками</td>
<td><code>Architecture: all</code></td>
</tr>
<tr>
<td><b>Section</b></td>
<td>Определяет задачу, для которой приложение обычно используется (группа приложений).<br>
Возможные значения: admin, base, comm, contrib, devel, doc, editors, electronics, embedded, games, gnome, graphics, hamradio, interpreters, kde, libs, libdevel, mail, math, misc, net, news, non-free, oldlibs, otherosfs, perl, python, science, shells, sound, tex, text, utils, web, x11</td>
<td><code>Section: misc</code></td>
</tr>
<tr>
<td><b>Description</b></td>
<td>Описание пакета.<br>
Описание состоит из двух частей: короткое описание (70 символов) на той же строке, и длинное описание на последующих строках, <b>начинающихся с пробела</b>.<br>
В расширенном описании все переводы строки игнорируются. Для вставки \n используется одиночная точка.</td>
<td><code>Description: Short.&lt;br&gt;␣Long &lt;br&gt;␣goes here.&lt;br&gt;␣.&lt;br&gt;␣New line.</code></td>
</tr>
<tr>
<th colspan="3"> — связи и зависимости — </th>
</tr>
<tr>
<td>Depends</td>
<td>Список пакетов через запятую, которые требуются для установки этого пакета.<br>
После имени пакета можно в круглых скобках указать ограничение на версию, используя операторы: &lt;&lt;, =, &gt;&gt;, &lt;=, &gt;=. Если оператор не указан — используется &gt;=</td>
<td><code>Depends: dpkg, libz (&gt;= 1.2.3), jpeg (= 6b), png (&lt; 2.0)</code></td>
</tr>
<tr>
<td>Pre-Depends</td>
<td>Список пакетов, которые требуются в процессе установки этого пакета.<br>
Эти зависимости могут потребоваться для скриптов установки пакета: например, пакет flash-installer требует wget<br>
Можно использовать ограничения на версию (см. Depends).</td>
<td><code>Pre-Depends: wget (&gt;= 1.0)</code></td>
</tr>
<tr>
<td>Conflicts</td>
<td>Список пакетов, которые не могут быть установлены одновременно с этим.<br>
Установка не удастся, если хоть один из перечисленных пакетов уже будет установлен.</td>
<td><code>Conflicts: crapscript</code></td>
</tr>
<tr>
<td>Replaces</td>
<td>Список пакетов, файлы которых модифицируются этим пакетом.<br>
Требуется в случае создания «пакета-патча», изменяющего что-либо: в противном случае при замене файлов чужого пакета возникнет ошибка при установке. У меня, например, такой пакет патчит UT2004 и убирает звук наводящейся ракетницы :)</td>
<td><code>Replaces: ut2004</code></td>
</tr>
<tr>
<td>Recommends</td>
<td>Список пакетов, рекомендуемых к установке<br>
Эти пакеты не обязательны, но обычно используются вместе с текущим</td>
<td><code>Recommends: superplatform</code></td>
</tr>
<tr>
<td>Suggests</td>
<td>Список пакетов, предлагаемых к установке.<br>
Эти пакеты не обязательны, но с ними прога работает ещё лучше :) По идее, менеджер пакетов должен предлагать установить их.</td>
<td><code>Suggests: supersh-modules</code></td>
</tr>
<tr>
<td>Build-Depends</td>
<td>(Только для Architecture: source)<br>
Список пакетов, требуемых для компиляции исходников.<br>
То же, что и Depends, но логически отделено.</td>
<td><code>Build-Depends: cmake</code></td>
</tr>
<tr>
<th colspan="3"> — экстра — </th>
</tr>
<tr>
<td>Installed-Size</td>
<td>Размер файлов пакета в килобайтах.<br>
Просто цифра, округлённая до ближайшего целого. Используется менеджером пакетов для определения суммарного требуемого объёма на диске.</td>
<td><code>Installed-Size: 3</code></td>
</tr>
<tr>
<td>Priority</td>
<td>Приоритет пакета: насколько он важен в системе<br>
Возможные значения: extra, optional, standard, important, required (такие пакеты не удаляются вообще!).</td>
<td><code>Priority: optional</code></td>
</tr>
<tr>
<td>Esssential</td>
<td>Если установить этот атрибут в значение «yes», пакет нельзя будет удалить.</td>
<td><code>Esssential: yes</code></td>
</tr>
<tr>
<td>Origin</td>
<td>Строка: откуда получены программы в пакете. Обычно используется URL сайта автора, почта или имя.</td>
<td><code>Origin: brain</code></td>
</tr>
<tr>
<td>X-Source</td>
<td>Полная ссылка на *.tar.gz архив с исходниками</td>
<td><code>[http://.../ X-Source]: ...*.tgz</code></td>
</tr>
</tbody></table><br>
Да, вот такие солидные возможности у контрольного файла :)<br>
А в нашем примере он выглядит так:<br>
<code>Package: supersh<br>
Version: 1.0-1<br>
Section: misc<br>
Architecture: all<br>
Depends: bash, sed (&gt;= 3.02-8)<br>
Maintainer: o_O Tync &lt;o-o-tync.habrahabr.ru&gt;<br>
Description: Super Shell Script<br>
␣A super example script.<br>
␣.<br>
␣It does nothing :)<br>
</code><br>
<br>
<h5>DEBIAN/copyright: © / лицензия</h5><br>
Текст лицензии. Файл не обязателен, но лучше подчеркнуть своё авторство ;)<br>
<br>
<h5>DEBIAN/changelog: история изменений</h5><br>
Changelog в специальном формате: используется dpkg для получения номера версии, ревизии, дистрибутива и важности пакета. Лучше посмотреть в [http://www.debian.org/doc/debian-policy/ch-source.html#s-dpkgchangelog официальной документации] ;) а я лишь приведу пример:<br>
<code>supersh (1.0-1) stable; urgency=medium<br>
<br>
* Testing.<br>
<br>
-- o_O Tync &lt;o-o-tync.habrahabr.ru&gt; Sun, 13 Dec 2009 00:11:46 +0300<br>
</code><br>
<br>
<h5>DEBIAN/rules: правила компиляции</h5><br>
Используется для управления компиляцией пакета: это когда <code>Architeture: source</code> :)<br>
См. [http://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules официальную документацию]<br>
<br>
<h5>DEBIAN/conffiles: список файлов конфигурации</h5><br>
Обычно пакеты содержат болванки конфигурационных файлов, например, размещаемых в /etc. Очевидно, что если конфиг в пакете обновляется, пользователь потеряет свой отредактированный конфиг. Эта проблема легко решается использованием папок типа «config.d», содержимое которых включается в основной конфиг, заменяя собой повторяющиеся опции.<br>
Файл «DEBIAN/conffiles» позволяет решить проблему иначе: он содержит список файлов конфигурации (по одному на строке). Если в текущей версии пакета один из этих файлов обновляется, то пользователь получает предупреждение о конфликте версий конфигов, и может выбрать: удалить, заменить, или сделать merge.<br>
С этой ситуацией наверняка сталкивался каждый линуксоид, копавшийся в конфигах :) А ноги растут отсюда.<br>
На каждой строке должен быть полный абсолютный путь до каждого конфига. Например:<br>
<code>/etc/supersh/init.conf<br>
/etc/supersh/actions.conf<br>
</code><br>
<br>
<h5>DEBIAN/dirs: список папок для создания</h5><br>
«Список абсолютных путей к папкам, которые требуются программе, но по каким-либо причинам не создаются.» — гласит официальная документация. На практике – здесь перечисляются все папки, так или иначе используемые программой: и где лежат бинарники, и которые используются программой.<br>
По одной на строке. Например:<br>
<code>/var/log/supersh<br>
/var/lib/supersh</code><br>
Удобно использовать для создания нескольких пустых папок.<br>
<br>
<h5>DEBIAN/menu: создание пунктов меню</h5><br>
Хитрый файл для создания пунктов меню. У меня он так и не заработал :) Складывается ощущение, что его содержимое используется либо в необычных оконных менеджерах, либо в каком-то консольном меню… или же использовалось ранее и было забыто :)<br>
Пример:<br>
<s><code>?package(supersh):needs="text" section="Applications/Programming" title="Super Shell Script" command="/usr/bin/super.sh"</code></s><br>
TODO: узнать зачем нужно. Об этом написано в <code>man5 menufile</code>, честно говоря я не вникал :)<br>
<br>
<h6>UPD: Правильный способ добавления пункта меню</h6><br>
Файл /DEBIAN/menu создаёт неизвестно что и непонятно где: элементы графического меню всё равно не создаются. Поэтому будем делать правильно :)<br>
В <code>/usr/share/applications</code> видим кучку <code>*.desktop</code> файлов: это и есть пункты меню. Они представляют собой текстовые файлы с синтаксисом наподобие ini-файла. Открываем, учимся, делаем так же и кладём получившийся <code>*.desktop</code> файл в <code>usr/share/applications/</code>. Иконка для него должна лежать в <code>usr/share/pixmaps</code>.<br>
После этого в postinst скрипт нужно добавить выполнение команды обновления меню <code>update-menus</code>:<br>
<code>if [ "$1" = "configure" ] &amp;&amp; [ -x "`which update-menus 2&gt;/dev/null`" ] ; then<br>
update-menus<br>
fi<br>
</code><br>
Работа со скриптами установки пакета будет рассмотрена далее.<br>
Спасибо [https://habrahabr.ru/users/condorious/ Condorious] за наводку :)<br>
<br>
<h5>DEBIAN/md5sums: контрольные суммы файлов</h5><br>
Используется для проверки целостности пакета. Важный файл.<br>
Заполняется так (cwd=корень пакета):<br>
<code>$ md5deep -r usr &gt; DEBIAN/md5sums</code><br>
<br>
<h5>DEBIAN/watch: мониторинг сайта, откуда была скачана прога</h5><br>
Функция полезна, если Вы мэйнтейните от нескольких десятков пакетов, и уследить за всеми обновлениями сложно.<br>
Файл содержит инструкции для программ uscan и uupdate. Используя эту возможность, можно следить за сайтом, откуда были получены исходники пакета, и обеспечивать контроль качества дистрибутива в целом.<br>
Пример:<br>
<code># Site Directory Pattern Version Script<br>
ftp.obsession.se /gentoo gentoo-(.*)\.tar\.gz debian uupdate<br>
</code><br>
И ещё пример для uscan(1):<br>
<code>[http://madwimax.googlecode.com/files/madwimax- version=3]<br>
madwimax.googlecode.com/files/madwimax-(.*)\.tar\.gz<br>
</code><br>
Лучше почитайте [http://dehs.alioth.debian.org/ официальную документацию], такие мощные вещи нечастно требуются простым смертным :)<br>
<br>
<h5>DEBIAN/cron.d: инсталляция заданий cron</h5><br>
Файл содержит кусок crontab для инсталляции. Пример объясняет всё:<br>
<code>#<br>
# Launches super.sh periodically<br>
#<br>
0 4 * * * root [ -x /usr/bin/super.sh ] &amp;&amp; usr/bin/super.sh <br>
</code><br>
<br>
<h5>DEBIAN/inid.d: init-скрипт</h5><br>
В этот файл пишется содержимое init-скрипта. О написании init-скриптов в инете можно найти <br>
<br>
<h4>Скриптинг</h4><br>
Мы подошли к самому интересному: встраиванию скриптов в deb пакеты. Скрипты позволяют управлять установкой, переустановкой и удалением пакета, выполняя действия, которые нельзя сделать простым копированием файлов в правильные места. Это может быть скачивание дополнительных файлов (как это делает flash-installer), изменение существующих, а также — вывод интерактивных (GUI или ncurses) диалогов, позволяющих пользователю сконфигурировать пакет под себя: например, mysql спрашивает какой установить пароль для root.<br>
Все скрипты выполняются от пользователя root (а как же ещё :). Также они получают аргументы (которые обрабатывать не обязательно), конкретизирующие на каком именно этапе находится установка. Подробнее об этом [http://www.debian.org/doc/debian-policy/ch-maintainerscripts.html#s-mscriptsinstact здесь].<br>
<br>
<h5>DEBIAN/(preinst|postinst|prerm|postrm): скрипты установки</h5><br>
Всего можно создать до четырёх скриптов в одном пакете:<br>
<table>
<tbody><tr>
<th>Скрипт</th>
<th>Назначение</th>
</tr>
<tr>
<th>DEBIAN/preinst</th>
<td>Выполняется перед установкой пакета: он может подготовить что-либо для успешной установки</td>
</tr>
<tr>
<th>DEBIAN/postinst</th>
<td>Выполняется сразу после установки пакета: он настраивает установленный пакет так, чтоб он был готов к работе. Здесь также выполняется интерактивная конфигурация пакета: это делается при помощи dh_input и файла DEBIAN/templates</td>
</tr>
<tr>
<th>DEBIAN/prerm</th>
<td>Выполняется непосредственно перед удалением пакета: обычно этот скрипт подчищает установочные пути пакета так, чтоб ничего лишнего не завалялось :)</td>
</tr>
<tr>
<th>DEBIAN/postrm</th>
<td>Выполняется сразу после удаления пакета: вычищает остатки</td>
</tr>
</tbody></table><br>
Обратите внимание, что ошибки, возникающие в этих скриптах <b>никак не логируются</b>: ничего интереснее кода возврата скрипта нигде не сохраняется, и логирование необходимо делать вручную! Пользователи одного моего пакета терпели неудачу при установке на Linux Mint, и не было даже возможности попросить у них лог ошибок (которого нету) чтобы выдебагать причину :)<br>
Рекомендую использовать в начале каждого скрипта следующую болванку: она будет сохранять в syslog все возникающие ошибки.<br>
<code>#!/bin/bash<br>
set -e # fail on any error<br>
set -u # treat unset variables as errors<br>
<br>
# ======[ Trap Errors ]======#<br>
set -E # let shell functions inherit ERR trap<br>
<br>
# Trap non-normal exit signals:<br>
# 1/HUP, 2/INT, 3/QUIT, 15/TERM, ERR<br>
trap err_handler 1 2 3 15 ERR<br>
function err_handler {<br>
local exit_status=${1:-$?}<br>
logger -s -p "syslog.err" -t "ootync.deb" "supersh.deb script '$0' error code $exit_status (line $BASH_LINENO: '$BASH_COMMAND')"<br>
exit $exit_status<br>
}<br>
<br>
... Ваш код установочного скрипта ...<br>
<br>
exit 0<br>
</code><br>
WARNING: болванка пока не тестировалась широко, проверьте лишний раз! На невозможность отладки наткнулся совсем недавно :)<br>
<br>
<h5>DEBIAN/templates: шаблоны для диалогов</h5><br>
Как уже было сказано, в скрипте DEBIAN/config можно задавать пользователю вопросы: ввести строку, выбрать один из вариантов, поставить галочку,… Этим занимается «библиотека» bash функций debhelper пакета debconf, умеющая кроме этого ещё массу полезных вещей. Здесь их не рассматриваю :)<br>
Файл DEBIAN/templates содержит данные, используемые при выводе диалоговых окон (GUI или ncurses). Файл содержит блоки, разделённые пустой строкой. Каждый блок определяет ресурсы, используемые в одном конкретном диалоговом окне.<br>
Шапка для всех типов диалогов стандартная:<br>
<code>Template: supersh/template-name<br>
Type: string<br>
Default: Default-value<br>
Description: Dialog-title<br>
␣Dialog-text<br>
</code><br>
Template — уникальный (в пределах одного пакета) идентификатор шаблона. Если в скрипте нужно вызвать определённый диалог — используется именно это имя.<br>
Type — тип шаблона. Определены такие типы: string, password, boolean, select, multiselect, text, note, error.<br>
Default-value — значение по умолчанию: пользователь может просто согласиться с ним.<br>
Description — как и в контрольном файле, состоит из двух полей: короткое описание, и длинный текст. Первое — это заголовок «окна», второе — более развёрнутое описание того, что требуется от пользователя. Рекомендуется не использовать слов вроде «введите», а сразу суть: «Приветствие скрипта», «Точка монтирования»,…<br>
<br>
<table>
<tbody><tr>
<th>Тип</th>
<th>Описание шаблона</th>
</tr>
<tr>
<th>string</th>
<td>Приглашение на ввод текстовой строки</td>
</tr>
<tr>
<th>password</th>
<td>Приглашение на ввод пароля.<br>
Для этого типа шаблона нет значения Default по понятным причинам :)</td>
</tr>
<tr>
<th>boolean</th>
<td>Галочка :) Имеет строковое значение «true» или «false»</td>
</tr>
<tr>
<th>select</th>
<td>Возможность выбора одного из нескольких вариантов.<br>
Варианты предлагаются в дополнительном атрибуте шаблона:<br>
<code>Choices: yes, no, maybe</code></td>
</tr>
<tr>
<th>multiselect</th>
<td>Возможность выбора нескольких вариантов галочками.<br>
Варианты предлагаются в дополнительном атрибуте шаблона:<br>
<code>Choices: sex, drugs, rock-n-roll</code></td>
</tr>
<tr>
<th>text</th>
<td>Выводит на экран текст: некоторая не очень важная информация</td>
</tr>
<tr>
<th>note</th>
<td>Выводит на экран текст: важная информация</td>
</tr>
<tr>
<th>error</th>
<td>Выводит на экран текст: очень важная информация, критическая.</td>
</tr>
</tbody></table><br>
Для шаблонов text, note, error также нет значения Default, так как они лишь отображают информацию :)<br>
Поиграемся с следующим шаблоном:<br>
<code>Template: supersh/greeting<br>
Type: string<br>
Description: Welcome message<br>
␣The message you wish the script to welcome you with.<br>
Default: Greetings, my master!<br>
</code><br>
<br>
<h5>Основы использования debconf и debhelper</h5><br>
Это лишь работоспособные наброски. В оригинале почитать о шаблонах и работе с ними можно здесь: <code>man 7 debconf-devel</code> :)<br>
Чтобы использовать шаблоны в своём скрипте настройки DEBIAN/config, необходимо сначала подключить функции debhelper:<br>
<code>. /usr/share/debconf/confmodule</code>. Также этот файл нужно подключить в скрипте postinst: иначе скрипт DEBIAN/config вообще не выполнится!<br>
Эти функции доступны в пакете debconf, не забудьте включить его в зависимости!<br>
Примитивный пример использования. Файл DEBIAN/config<br>
<code>#!/bin/bash -e<br>
<br>
# Подключение команд debconf<br>
. /usr/share/debconf/confmodule<br>
<br>
case "$1" in<br>
configure|reconfigure)<br>
# Запрос<br>
db_input medium "supersh/greeting" || true # инициализация<br>
db_go || true # вывод запроса на экран<br>
# Обработка ответа<br>
db_get "supersh/greeting" # Получение значения в переменную $RET<br>
greeting="$RET" <br>
echo "$greeting" &gt; /etc/supersh/greeting.txt<br>
;;<br>
*)<br>
echo "config called with unknown argument \`$1'" &gt;&amp;2<br>
exit 1<br>
;;<br>
esac<br>
# Запрос<br>
db_input medium "supersh/greeting" || true # инициализация<br>
db_go || true # вывод запроса на экран<br>
<br>
# Обработка ответа<br>
db_get "supersh/greeting" # Получение значения в переменную $RET<br>
greeting="$RET" <br>
echo "$greeting" &gt; /etc/supersh/greeting.txt<br>
</code><br>
Здесь уже кроется неприятная засада: обратите внимание, что функции db_input передаётся приоритет диалога medium. Для debconf можно установить минимальный приоритет: диалоги с приоритетом ниже которого не отображаются, а берётся значение по умолчанию (Default шаблона)! Чтобы этого ТОЧНО не случилось — используем приоритет critical :) Кроме того, при установке из GUI порог вывода вопросов выше, и многие из них не отображаются вообще.<br>
Возможные приоритеты: low — всегда используется default, medium — дефаулт обычно вполне подходит, high — дефаулт нежелателен, critical — внимание пользователя жизненно важно.<br>
<code>|| true</code> используется чтобы скрипт не помер из-за ключика "-e" переданного bash.<br>
В этом скрипте тоже рекомендуется использовать ту болванку для отлова ошибок, иначе с распространяемым пакетом могут возникнуть проблемы при отладке :)<br>
Все тонкости использования debconf (функции, способы, параметры, коды ошибок) описаны в достаточно многословном мане: <code>man debconf-devel</code>.<br>
<br>
И последнее: при удалении пакета командой purge — debconf должен также вычистить из своей базы сведения о пакете. Например, он сохраняет выбор пользователя при запросах db_input. <br>
Чтобы вычистить эти данные, нужно в postinst-скрипт добавить следующее:<br>
<code>if [ "$1" == "purge" ] &amp;&amp; [ -e /usr/share/debconf/confmodule ] ; then<br>
. /usr/share/debconf/confmodule<br>
db_purge<br>
fi<br>
</code><br>
<br>
<h4>Собираем пакет! :)</h4><br>
Ура! Все нужные файлы созданы, лежат по нужным папочкам. Теперь пора собирать пакет :)<br>
Первое, что нужно сделать — это рекурсивно выставить всем файлам в корне пакета пользователя и группу root:root (или другие, если потребуется). Это нужно затем, что файлы пакета упаковываются в tar.gz архив который сохраняет и права доступа к файлам, и владельца. Потому нужно выполнить:<br>
<s><code>$ sudo chown -R root:root .</code></s><br>
Однако делать это не обязательно. Есть отличная команда fakeroot которая при создании архива подменит владельца файлос root-ом.<br>
В нашем примере, скрипт должен иметь бит выполнимости.<br>
Потом выходим на папку назад, чтоб было видно корневую папку пакета, и пакет создаётся <s>лёгким пинком</s> сам:<br>
<code>$ fakeroot dpkg-deb --build supersh</code><br>
Созданный пакет необходимо переименовать, чтобы он соответствовал порядку именования *.deb пакетов: &lt;имя пакета&gt;_&lt;версия&gt;_&lt;архитектура&gt;.deb<br>
<code>$ mv supersh.deb supersh_1.0-1_all.deb</code><br>
Всё, пакет готов!<br>
<br>
<h5>Автоматическая проверка пакета</h5><br>
Существует утилита lintian, позволяющая проверить пакет и выявить типичные ошибки в его структуре. Делается это так:<br>
<code>$ lintian supersh_1.0-1_all.deb</code><br>
<br>
<h5>Установка пакета</h5><br>
<code>$ sudo dpkg -i supersh_1.0-1_all.deb</code><br>
<br>
<h4>Создаём собственный репозиторий пакетов</h4><br>
Теперь у нас есть собственный пакет. Когда их будет несколько, и тем более — с зависимостями, окажется, что намного удобнее быстренько поднять собственный локальный микро-репозиторий, и включить его в список источников менеджера пакетов :) Здесь я опишу быстрый HowTo «как создать свой репозиторий». Идею будет легко развить, почитывая соответствующую документацию :)<br>
Сперва установим помощника:<br>
<code>$ sudo apt-get install reprepro</code><br>
<br>
<h5>Описание будущего репозитория</h5><br>
Центр репозитория — его описание. Главное в нём — список компонент репозитория. Мы создадим компоненты «soft» и «games».<br>
Выберите папку для будущего репозитория. Все действия производятся из её корня.<br>
Создаём файл conf/distributions следующего содержания:<br>
<code>Description: my local repository<br>
Origin: Ubuntu<br>
Suite: testing<br>
AlsoAcceptFor: unstable experimental<br>
Codename: karmic<br>
Version: 5.0<br>
Architectures: i386 amd64 source<br>
Components: soft games<br>
UDebComponents: soft games<br>
</code><br>
В нашем деле создания простого репозитория все поля не играют принципиальной роли, и используются лишь для визуального определения «что есть что» :)<br>
<br>
<h5>Создание репозитория</h5><br>
Репозиторий описан! Теперь сгенерируем болванку на основе описания. Команды выполняются в корне репозитория:<br>
<code>$ reprepro export<br>
$ reprepro createsymlinks</code><br>
И добавим готовый репозиторий в /etc/apt/sources.list:<br>
<code>deb file:///path/to/repo/ karmic soft games</code><br>
Этот репозиторий можно также расшарить при помощи веб-сервера.<br>
<br>
<h5>Управление пакетами в репозитории</h5><br>
В корень репозитория кладём *.deb файлы для добавления, и добавляем их в компоненту soft дистрибутива karmic:<br>
<code>reprepro -C soft includedeb karmic *.deb</code><br>
теперь пакеты доступны из менеджера пакетов :)<br>
Удаление пакетов:<br>
<code>reprepro -C soft remove karmic supersh</code><br>
<br>
<h4>Финиш</h4><br>
В статье рассмотрены материалы по созданию deb пакетов. Акцент сделан на моментах, для которых в сети нет достаточно наглядного описания. Надеюсь, что моя попытка изложить просто и понятно не провалилась :)<br>
Домашнее задание :)) — вполне неплохо документированные вещи, которые легко найти в man'ах и статьях:<br>
<ul>
<li>Создание source пакетов, компилирующих исходники: на примере Zabbix об этом отлично рассказал хабраюзер [https://habrahabr.ru/users/mahoro/ mahoro] в [http://mahoro.habrahabr.ru/blog/78086/ своей статье]</li>
<li>Debconf, debhelper в конфигурационных скриптах: читаем маны по debconf-devel и debhelper. Они также позволяют создать скелет пакета командой dh_make.</li>
<li>Продвинутые способы создания документации в пакетах: файлы DEBIAN/docs, DEBIAN/manpage.*</li>
<li>Создание init скриптов</li>
<li>Управление заданиями cron</li>
<li>Подписывание репозитория ключём gpg</li>
</ul><br>
<br>
<b>UPD:</b> @ICD2 [https://habrahabr.ru/post/78094/#comment_2279550 подсказывает], что есть GUIшная прога для создания пакетов: [http://giftwrap.tuxfamily.org/ GiftWrap]<br>[http://rus-linux.net/nlib.php?name=/MyLDP/po/giftwrap/create-ubuntu-packages-with-giftwrap.html giftWrap]<br>
<br>
Cheers! :)<br>
<br>
P.S. В статье наверняка встречаются неточности и ошибки. Давайте причешем её вместе! :)

[https://habrahabr.ru/post/78094/ взято тут...]