Создаём список пакетов:

$ dpkg-scanpackages . /dev/null | gzip -9c > ./Packages.gz

Может быть, нам будет выведено сообщение типа:

Dpkg-scanpackages: warning: Packages in archive but missing from override file: dpkg-scanpackages: warning: fossil linux-headers-3.8.0-avl9-pae linux-image-3.8.0-avl9-pae pdfsam sublimetext virtualbox-4.2 xserver-xorg-input-wacom zotero dpkg-scanpackages: info: Wrote 8 entries to output Packages file.
Теперь в нашем репозитории 8 пакетов. Отлично, добавляем наш репозиторий в файл:

строчкой типа:

Deb file:///home/имя_пользователя/zips/virensdebianrepository ./
Теперь нужно обновить список пакетов, чтобы они стали доступны для установки:

Всё, теперь можно установить, к примеру, свежесобранный текстовый редактор Sublime Text 2 (отличная инструкция там) как всегда: Теперь, для того, чтобы установить SublimeText достаточно сделать:

# apt-get install sublimetext

Reading package lists... Done Building dependency tree Reading state information... Done The following NEW packages will be installed: sublimetext 0 upgraded, 1 newly installed, 0 to remove and 245 not upgraded. Need to get 0 B/11.4 MB of archives. After this operation, 17.4 MB of additional disk space will be used. WARNING: The following packages cannot be authenticated! sublimetext Install these packages without verification ? Y Selecting previously deselected package sublimetext. (Reading database ... 247813 files and directories currently installed.) Unpacking sublimetext (from ..././sublimetext_2.0.2_i386.deb) ... Setting up sublimetext (2.0.2) ... Всё, пакет будет распакован и установлен, а то, что он из местного репозитория, видно вот тут: (from ..././sublimetext_2.0.2_i386.deb)

Заключение

Описанные в этом посте рецепты - блюда на скорую руку, а не фуагра с трюфелями. Для больших репозиториев или сложных пакетов придётся-таки ознакомиться с документацией и руководствами . Ещё можно воспользоваться программой , которая умеет не только создавать репозитории, но и записывать их на CD/DVD диски.

Отдельное спасибо тов. brainstream , который указал на баг в посте с отрисовкой окружения PRE. Такое бывает, когда доверяешь хаскельным поделкам вроде pandoc:-)

Да, если есть что добавить - пишите в комментариях, но учтите, что пост - именно на скорую руку, без нужды перечитывать фолианты Debian Packaging Guidelines и прочую квантовую физику.

Анонимный комментирует...

Ошибка у вас в тексте:
"Теперь, для того, чтобы установить Skype достаточно сделать:

# apt-get install sublimetext "

Анонимный комментирует...

Распаковывать пакеты можно через dpkg-deb:
$ dpkg-deb -x что.deb куда/

Анонимный комментирует...

Всегда использовал dpkg -e и dpkg -x для полной распаковки пакета и быстрой правки файлов или зависимостей в контрольных файлах. А так же использовал checkinstall вместо make install для создания пакета при компиляции чего либо. Мне кажется эти утилиты стоит упомянуть.

virens комментирует...

Сборка пакетов из исходников в Debian - это от лукавого! Я сейчас припомню свой опыт:

1. В deb-пакете должны быть прописаны майнтейнер и прочая чепуха, без которой (сюрприз-сюрприз!) пакет не соберется.

2. Вы собрали, установили и думаете, что на этом всё? Не тут-то было, добрый aptitude может снести пакет ко всем чертям при установке чего-то другого. Вам знакомо такое чувство: как? где? что? я же уже ставил этот пакет!!! Ну вот такой он aptitude - весь из себя православный, а значит, патриархальный и вольнодумства не позволяющий.

3. Поэтому срочно необходим маневр: aptitude hold package. "Что, хорошо держится? А теперь будьте любезны - отлепите!" (с) Поскольку с этого момента aptitude будет ругаться, что он не в состоянии разрулить зависимости, не снеся вашего пакета.

4. На этом нервы мои сдали... И я открыл для себя Gentoo, а мои волосы снова стали мягкими и шелковистыми!

virens комментирует...

@iv_vl комментирует...
И я открыл для себя Gentoo, а мои волосы...
Наглый пиар Генты?! В моём бложике??? Нет пути! ;-)

1. В deb-пакете должны быть прописаны майнтейнер и прочая чепуха
Стандартное policy - надо же знать, кому дать в морду за сломанный пакет:-) И потом, это всяко лучше того бедлама, который творится в RPM-ных федорах и зюзях.

2. Вы собрали, установили и думаете, что на этом всё? Не тут-то было, добрый aptitude может снести пакет ко всем чертям при установке чего-то другого.
Только если ты ставишь пакет старой версии - например, у меня стоит hold на IceWM, который я поставил из Lenny (придурок-майнтейнер запихнул в Squeeze айс с отломанным треем). Аптитуда тебя предупредит перед подобными манёврами, если что.

3. Поэтому срочно необходим маневр: aptitude hold package.... aptitude будет ругаться, что он не в состоянии разрулить зависимости
Это ложь и провокация: только если ты не влепил hold на что-нибудь типа gcc или glibc, нормально оно разруливать зависимости будет. В отличие от RPM-ов, которые любят сдаваться сразу в стиле "Ну не шмогла я, не шмогла" :-)

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

4. На этом нервы мои сдали...
Как-то ты быстро сдулся. Кстати, а как дела с зависимостями в генте? Как вы там живёте-то с конпелянием на каждый чих?
Я это...не троллинга ради.... народ интересуется.

iv_vl

Эта статья не завершена. Вы можете помочь в ее написании

Исправив стилистику статьи

Добавив больше информации о подготовке исходных кодов для дебианизации

Дистрибутивы, основанные на Debian – это не только отличная система управления пакетами APT , которая сама разрешает зависимости, но и удобные инструменты для создания пакетов и своих репозиториев. Если уж вы решились собрать программу из исходников, то советую ещё изучить, как дебианизировать исходники. Это отнимет чуть больше времени, чем стандартное

./ configure && make && make install make uninstall

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

Классификация случаев сборки

Возможны следующие случаи сборки пакетов:

Сборка из исходников;

Сборка из бинарных файлов;

исходники или бинарные файлы берутся:

Не из репозитория;

Из репозитория другого дистрибутива;

Из репозитория другого выпуска Ubuntu, из PPA или из Debian;

дебианизация:

Недоступна;

Берётся из репозитория Ubuntu, из PPA или из Debian:

• Из другой версии программы;

  Из текущей версии программы:

  • Не из репозитория текущего выпуска Ubuntu;

    Из репозитория текущего выпуска Ubuntu;

причина сборки:

Ни в репозитории Ubuntu текущего выпуска, ни в PPA нет нужной версии программы;

Доступная версия программы по каким-либо причинам не устраивает (не устраивает код или данные программы, параметры конфигурации или управляющая информация пакета);

И то, и другое.

Сборка из исходников

Что необходимо

Полное Руководство начинающего разработчика Debian доступно .

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

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

sudo apt-get install autoconf automake libtool autotools-dev dpkg-dev fakeroot

Можно так же autobook - это документация по утилитам GNU Autoconf , Automake , и Libtool . Ну и конечно то, что требуют сами исходные коды для корректной сборки.

Создание ключа шифрования

Этот шаг не обязателен, его можно пропустить.

Чтобы создать ключ, зайдите в Приложения → Стандартные → Пароли и ключи шифрования . В открывшемся окне, в меню Ключ → Новый ключ , выбираем ключ pgp . Заполняем поля Полное имя и Электронный адрес .

В мире свободного программного обеспечения, для предотвращения «краж» или «подделок», принято подписывать свои «ценные» вещи электронным ключом, открытая часть которого хранится на общедоступных серверах и позволяет другим пользователям легко выяснить подлинность и целостность той или иной вещи.
Поэтому отнеситесь к созданию ключа очень ответственно.
Никто вас не заставляет вписывать сюда реальные имя и фамилию, или ещё какие-нибудь личные данные, но если вас не разыскивает интерпол - думаю указать фамилию и имя будет верным решением, хотя можно и просто свой ник В общем, решайте сами. А вот почтовый адрес укажите реальный, и который вы не поменяете.

Можно завести ящик, если ещё нет, на каком-нибудь популярном почтовом сервере: например, gmail.com или yandex.ru .
Это позволит в будущем легко связаться с вами человеку, который вас не знает, но по той или иной причине встретил «вещь», подписанную вами.
Далее вас спросят ввести пароль, как дополнительную защиту. Он может быть полезен, если вы будете использовать закрытый ключ на машинах, которым вы не можете на 100% доверять. Обратная сторона - вам придётся вводить пароль каждый раз, как только вы будете что-то подписывать.

Хотя последняя версия программы seahorse имеет демон, который автоматически запускается в сеансе GNOME , и умеет «запоминать пароль» на время сеанса, но пока не все программы умеют с ней работать.

Итак, вы создали ключ - теперь его можно будет использовать при создании пакетов.
Для этого, в файл ~/.bashrc, или в другой стартовый скрипт, вашего любимого шелла (для zsh ~/.zshrc), нужно вписать переменные

Export DEBEMAIL=ваш@имейл

На основании e-mail будет искаться ключ в pgp, при подписи пакета.
Нужно завершить сеанс и зайти заново, чтобы изменения вступили в силу.
Помните, что если вы бэкпортируете пакет, дебианизированный не вами, обязательно нужно изменить версию командой

dch -i

для того, чтобы в изменения вписался ваш e-mail. А для того, чтобы ваш открытый ключ попал на сервер, необходимо в настройках «seahorse → Пароли и ключи шифрования», настроить соединение с сервером публичных ключей.
Для этого, в меню Правка→Параметры на закладке Публикация ключей необходимо поставить галку Публиковать ключи… .
Теперь можно выбрать ключ и в меню по правой кнопке выбрать Синхронизировать и опубликовать ключи .

Дебианизация недоступна

Итак, у нас есть только gcoolprog-0.5.3.tar.gz .

Обычно я выполняю следующие действия:

Предварительно подготавливаю рабочую директорию

"http://<путь до файла>" #можно конечно и просто через браузер скачать но обычно так быстрее

Получаем файл gcoolprog-0.5.3.tar.gz . Распакуем его перейдем в полученный каталог:

tar zxvf gcoolprog-0.5.3.tar.gz cd gcoolprog-0.5.3

Для корректной сборки нужно, чтобы корневая директория содержала не только название, но и версию!

./ configure --prefix =/ usr && make

Если команда выполнилась успешно, то осталось только дебианизировать.

Дебианизация

Ничего страшного в этом нет, как я уже говорил есть скрипты, которые сильно упрощают этот процесс.
Вообще смысл всей этой процедуры - создать директорию debian в корне исходников, с нужными файлами конфигурации и скриптом(ами).
Для этого, в корне исходных текстов, выполним

Dh_make --createorig

На что мы должны получить следующий диалог

Type of package: single binary, multiple binary, library, kernel module or cdbs? s Maintainer name: denis Email-Address: [email protected] Date: Mon, 13 Aug 2007 12:40:33 +0400 Package Name: gcoolprog Version: 0.5.3 License: blank Type of Package: Single Hit to confirm:

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

Но мы с вами молодцы и всё у нас прошло без ошибок - появился каталог debian в корне исходников, посмотрев его содержимое, Вы увидите кучу файлов (расширение.ex) с примерами на все случаи жизни.

Description:

Вместо и (без угловых кавычек) нужно вписать описание, что это за программа.
Именно эти сведения увидит пользователь, когда посмотрит описание пакета.
Второй момент - это поправить файл debian/rules
в секции binary-arch : нужно раскомментировать (т.е. убрать # в начале строки)

Dh_install

без этого мы получим пустой пакет.
Иногда debian/rules содержит лишь:

%: dh $@

Что приемлемо с использованием debhelper.
Этих настроек будет достаточно для сборки пакета с одной программой, которая не содержит разделяемых библиотек, т.е. только бинарник в /usr/bin и данные в /usr/share.

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

Теперь, соберём пакет:

В директории выше, т.е. в ~/src/gcoolprog/0.5.3, мы получим файлы

Gcoolprog_0.5.3-1.diff.gz gcoolprog_0.5.3-1_i386.changes gcoolprog_0.5.3-1_i386.deb gcoolprog_0.5.3.orig.tar.gz

Вот теперь мы можем установить пакет

dpkg -i * .deb

Дебианизация берётся из репозитория Ubuntu, из PPA или из Debian

Дебианизация берётся из другой версии программы

В этом случае, очень удобно взять дебианизацию оттуда и поправить для новой версии.

Как я уже сказал, возможно нам повезёт и достаточно будет только сменить версию. Но не будем гадать.

Ниже я не буду комментировать то, что описано в предыдущем решении.

mkdir ~/ src/ gcoolprog mkdir ~/ src/ gcoolprog/ 0.5.3 cd ~/ src/ gcoolprog/ 0.5.3 wget "http://<путь до файла>"

получаем файл gcoolprog-0.5.3.tar.bz2

bunzip2 gcoolprog-0.5.3.tar.bz2 gzip gcoolprog-0.5.3.tar mv gcoolprog-0.5.3.tar.gz gcoolprog_0.5.3.orig.tar.gz

теперь распаковываем его

tar zxvf ./ gcoolprog_0.5.3.orig.tar.gz

скачиваем предыдущую версию с http://packages.ubuntu.com или http://packages.debian.org , файл gcoolprog_0.5.1.diff.gz (в самом низу в секции More Information on gcoolprog)

wget "http://archive.ubuntu.com/ubuntu/pool/universe/g/gcoolprog/gcoolprog_0.5.1.diff.gz" gunzip gcoolprog_0.5.1.diff.gz patch -p0 < ./ gcoolprog_0.5.1.diff

получаем директорию

~/ src/ gcoolprog/ 0.5.3/ gcoolprog-0.5.1/ debian

копируем каталог gcoolprog-0.5.1/debian в директорию ~/src/gcoolprog/0.5.3/gcoolprog-0.5.3

cp -a ~/ src/ gcoolprog/ 0.5.3/ gcoolprog-0.5.1/ debian ~/ src/ gcoolprog/ 0.5.3/ gcoolprog-0.5.3 dch -i

этой командой изменяется файл debian/changelog например увидим

Gcoolprog (0.5.1-1ubuntu2) feisty; urgency =low * -- denis < ubuntu_user@ mail.ru>

но поскольку у нас версия 0.5.3, то нужно изменить значения на

Gcoolprog (0.5.3-1ubuntu1) feisty; urgency =low * New upstream release. -- denis < ubuntu_user@ mail.ru> Mon, 13 Aug 2007 14 :13 :27 +0400

сохраните изменения. Теперь можно выполнить команду сборки в пакет.

Dpkg-buildpackage -rfakeroot

получим файлы

cd .. ls -1 gcoolprog_0.5.3-1 .diff.gz gcoolprog_0.5.3-1 _i386.changes gcoolprog_0.5.3-1 _i386.deb gcoolprog_0.5.3.orig.tar.gz dpkg -i * .deb

Дебианизация берётся из текущей версии программы

Дебианизация берётся не из репозитория текущего выпуска Ubuntu

Для Debian нужно использовать сайт http://packages.debian.org , для Ubuntu - http://packages.ubuntu.com . Тогда, например, в Ubuntu ищем пакет gcoolprog в репозитории будущего релиза.

Предварительно подготовим рабочую директорию

mkdir ~/ src/ gcoolprog mkdir ~/ src/ gcoolprog/ 0.5.3 cd ~/ src/ gcoolprog/ 0.5.3

теперь скачиваем три файла

wget http:// archive.ubuntu.com/ ubuntu/ pool/ universe/ g/ gcoolprog/ gcoolprog_0.5.3-1 .dsc wget http:// archive.ubuntu.com/ ubuntu/ pool/ universe/ g/ gcoolprog/ gcoolprog_0.5.3.orig.tar.gz wget http:// archive.ubuntu.com/ ubuntu/ pool/ universe/ g/ gcoolprog/ gcoolprog_0.5.3-1 .diff.gz

или тоже самое, но одной командой

Dget http:// archive.ubuntu.com/ ubuntu/ pool/ universe/ g/ gcoolprog/ gcoolprog_0.5.3-1 .dsc

из пакета devscripts
затем распакуем командой

Dpkg-source -x ./ gcoolprog_0.5.3-1 .dsc

получим каталог gcoolprog-0.5.3.Перейдём в него и сменим версию:

cd gcoolprog-0.5.3 dch -i gcoolprog (0.5.3-1ubuntu1) feisty; urgency =low * backport from gutsy -- denis < ubuntu_user@ mail.ru> Mon, 13 Aug 2007 14 :13 :27 +0400

теперь можно собирать пакет

Dpkg-buildpackage -rfakeroot

получим файлы

cd .. ls -1 . gcoolprog_0.5.3-1 .diff.gz gcoolprog_0.5.3-1 _i386.changes gcoolprog_0.5.3-1 _i386.deb gcoolprog_0.5.3.orig.tar.gz dpkg -i * .deb

Дебианизация берётся из репозитория текущего выпуска Ubuntu

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

Для сборки понадобятся следующие пакеты: build-essential devscripts fakeroot. Потребуются также пакеты для разработки, мы их установим в дальнейшем.

Скачиваем исходники:

cd ~/ src apt-get source gcoolprog

apt-get source скачивает исходники из репозитория Ubuntu в текущую директорию. Многие пакеты в репозитории имеют общие друг с другом исходники, поэтому кроме исходников выбранного пакета могут скачаться и исходники других пакетов (общие для нескольких пакетов исходники).

Устанавливаем необходимые для сборки пакеты для разработки:

sudo apt-get build-dep gcoolprog

Собираем пакеты:

cd gcoolprog-0.5.3 debuild -b -us -uc

debuild следует запускать в директории исходников. Параметры -b -us -uc передаются программе dpkg-buildpackage. Первый требует собирать только бинарные пакеты, второй и третий - не подписывать цифровой подписью, соответственно, пакет исходников и файл.changes. Получившиеся в результате сборки пакеты будут в директории на один уровень выше.

Сборка из бинарных файлов

Ниже идёт пример как можно поступить в случае, если доступен только deb-пакет и нет его дебианизированных исходников.

Предположим, что работаем в каталоге ~/tmp . Создадим подкаталог ~/tmp/someprog , чтобы распаковать файлы какого-нибудь пакета, нужно выполнить

dpkg -x ~./ tmp/ some-prog-123 .deb ./ someprog

Для того, чтобы извлечь контрольную информацию, выполним

mkdir ~/ tmp/ someprog/ DEBIAN dpkg -e ~/ tmp/ some-prog-123 .deb ./ someprog/ DEBIAN

ну а теперь, чтобы всё это собрать обратно в пакет, нужно выполнить

dpkg -b ./ someprog ~/ tmp/ some-prog-123 -new.deb

В каталоге ~/tmp/someprog/DEBIAN содержатся файлы, описывающие, что это за пакет, от чего он зависит, и контрольные суммы файлов, находящихся в нём. Для того, чтобы собрать свой пакет, нужно поместить файлы в каталоге ~/tmp/someprog так, как будто это корневой каталог.То есть, если нужно, чтобы файл установился в /usr/bin ,нужно его поместить в каталог ~/tmp/someprog/usr/bin , ну и, соответственно, если что-то должно лежать в /etc , то в ~/tmp/someprog/etc и т.д.

Затем в ~/tmp/someprog создать каталог DEBIAN, обязательно большими буквами, и в нём файл ~/tmp/someprog/DEBIAN/control , в этом файле описывается название пакета, его зависимости и описание, формат очень простой. Например:

Package: libcurl3 Version: 7.15.2-2 Section: libs Priority: optional Architecture: i386 Depends: libc6 (>= 2.3.5-1), libcomerr2 (>= 1.33-3), libidn11 (>= 0.5.18), libkrb53 (>= 1.4.2), libssl0.9.8 (>= 0.9.8a-1),zlib1g (>= 1:1.2.1), ca-certificates Suggests: libldap2 Replaces: libcurl2 (<< 1:7.11.2-2) Installed-Size: 324 Maintainer: Domenico Andreoli Source: curl Description: Multi-protocol file transfer library libcurl is designed to be a solid, usable, reliable and portable multi-protocol file transfer library. . SSL support is provided by OpenSSL. To enable LDAP support package libldap2-dev is required. . This is the shared version of libcurl. . Homepage: http://curl.haxx.se

Ну а теперь собрать:

dpkg -b ./ someprog some-prog-123 -new.deb

Этой информации достаточно, чтобы собрать/пересобрать простенький пакет. На самом деле можно ещё запускать скрипты при установке пакета, при его удалении и много чего ещё, что нужно нормальному maintainer"у.

→ Инструкция по сборке deb-пакета

В сети существует не мало статей о том как собрать deb-пакет, но к сожалению не все из них будут понятны для разработчика, который решил сделать сборку впервые. Итак, у вас есть код. Он полезен, хорош, но требует некоторых навыков и усилий при установке на сервер или десктоп. Чтобы избежать ручной работы связанной с копированием файлов, манипуляций с базой данных, настройкой скриптов start-stop (для демонов) и настройкой конфигов, вы решили собрать все в deb-пакет.

В идеале, правильный deb-пакет должен быть подписан gpg-ключом. Иначе apt будет считать пакет ненадежным и будет выдавать соответствующее предупреждение. Но эту часть мы пока пропустим. Мануал о том как создать gpg-ключ и как подписать deb-пакет gpg-ключом рассмотрим позднее.

Шаг 1. Устанавливаем утилиты, которые потребуются для сборки вашего пакета :

Sudo apt-get install autoconf automake libtool autotools-dev dpkg-dev fakeroot

Шаг 2. Создаем корневой каталог для будущего пакета и копируем все файлы вашей утилиты в этот каталог, которые потребуются для работы и установки . Например:

Mkdir -p /home/username/deb/my_package cp /some_source_files /home/username/deb/my_package

Если ваша утилита будет находиться в папке:

/usr/local/share/my_project

/home/username/deb/my_package/usr/local/share/my_project

Шаг 3. Создаем в корне пакета каталог DEBIAN.

Имя каталога обязательно должно состоять из заглавных букв. В данном каталоге содержится мета-информация которая используется при установке.

Cd /home/username/deb/my_package mkdir DEBIAN

Далее, в каталоге DEBIAN создаем обязательный текстовый файл - control . В данном файле содержится основная информация о пакете. В файле, на каждой строке содержатся пары ключ-значение, разделенные двоеточием.

Cd ./DEBIAN touch control

Пример файла:

Package: my-package Version: 1.0.0 Provides: my-package Maintainer: Vasiliy Batareikin Architecture: all Section: web Priority: optional Pre-Depends: gcc, make, perl (>= 5.10), mysql-server Depends: gcc, make, perl (>= 5.10), perlmagick, mysql-server, unzip, rar Description: My first debian package

Package – Имя пакета. Допустимые символы . Обязательный параметр .

Version – Версия пакета. Обязательный параметр .

Provides – Имя приложения регистрируемое в системе.

Maintainer – Имя и почта мэйнтейнера пакета. Обязательный параметр .

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

Section – Определяет группу приложений. Обязательный параметр .

Priority – Приоритет пакета. Параметр определяет насколько важен ваш пакет в системе.

Pre-Depends – Список пакетов через запятую, которые необходимы в процессе установки вашего пакета. Менеджер пакетов автоматически усатновит указанные пакеты.

Depends – Список пакетов через запятую, которые требуются для работы этого пакета. Менеджер пакетов автоматически усатновит указанные пакеты.

Description – Описание пакета. Обязательный параметр .

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

Cd ./DEBIAN touch preinst postinst prerm postrm chmod 775 preinst postinst prerm postrm

preinst – Выполняется перед установкой пакета.

postinst – Выполняется сразу после установки пакета.

prerm – Выполняется непосредственно перед удалением пакета.

postrm – Выполняется сразу после удаления пакета.

Шаг 4 . Сборка пакета .

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

Введение

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

Архив control.tar.gz, содержащий скрипты, написанные майнтенером пакета, использующиеся при установке/удалении пакета, а так же другие служебные файлы;

Архив data.tar.gz, содержащий двоичные файлы программы, ради которой создан пакет;

Файл debian-binary.

Поскольку содержимое пакета может в будущем измениться (будет новый номер версии в debian-binary), то собирать deb-пакет при помощи программ tar, gzip, ar не рекомендуется и этот вариант в статье рассматриваться не будет.

Собирается пакет программой dpkg из специально подготовленной структуры каталогов:

Path/to/dir/file1

Path/to/dirX/fileX

Файлы и каталоги, предназначенные для установки в систему. Их расположение в архиве соответствует положению их в файловой системе если считать от корня. Например файл usr/share/doc/package/copyright в deb-архиве после установки будет находиться в /usr/share/doc/package/copyright (все они будут упакованы в архив data.tar.gz);

Каталог DEBIAN/, содержащий служебную информацию о пакете. Содержимое этого каталога при сборке будет упаковано в архив control.tar.gz;

Создание пакета Geany (A fast and lightweight IDE)

configure

Команда configure запущенная с ключем –help выводит список параметров, которые можно передать ей.

$ ./configure ... checking dependency style of gcc... (cached) gcc3 checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... no checking for cxx... no checking for cc++... no checking for cl.exe... no checking for FCC... no checking for KCC... no checking for RCC... no checking for xlC_r... no checking for xlC... no checking whether we are using the GNU C++ compiler... no checking whether g++ accepts -g... no checking dependency style of g++... none configure: error: No C++ compiler not found. Please install a C++ compiler.

Просматриваем вывод команды, если в конце строки "no" это означает, что в системе нет необходимых для компиляции данной программы вспомогательных программ и библиотек. Вывод малоинформативен -нет явного соответствия между ошибкой и пакетом который требуется до установить. Зная, что в Ubuntu часто пакеты с библиотеками бывают разбиты на два типа:

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

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

Устанавливаем требуемые пакеты.

# aptitude install autoconf automake libtool autotools-dev dpkg-dev fakeroot intltool-debian intltool ... Следующие НОВЫЕ пакеты будут установлены: autoconf automake autotools-dev build-essential{a} dpkg-dev g++{a} g++-4.3{a} gettext{a} intltool intltool-debian libltdl7-dev{a} libstdc++6-4.3-dev{a} libtool m4{a} 0 пакетов обновлено, 14 установлено новых, 0 пакетов отмечено для удаления, и 0 пакетов не обновлено. Необходимо получить 10,2MБ архивов. После распаковки 35,9MБ будет занято. Хотите продолжить? Y ...

Проверяем. Снова запускаем./configure.

$ ./configure ... checking pkg-config is at least version 0.9.0... yes checking for GTK... configure: error: Package requirements (gtk+-2.0 >= 2.8.0) were not met: No package "gtk+-2.0" found Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. Alternatively, you may set the environment variables GTK_CFLAGS and GTK_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details.

Ошибка. Требует пакет gtk+-2.0. Как показали поиски на английских форумах - пакет все же называется libgtk2.0-dev. Ставим. Как показывает вывод ниже - лучше найти УЖЕ скомпилированный DEB пакет - благо на это есть реальные шансы.

# aptitude install libgtk2.0-dev ... Следующие НОВЫЕ пакеты будут установлены: debhelper{a} html2text{a} libatk1.0-dev{a} libcairo2-dev{a} libdirectfb-dev{a} libdirectfb-extra{a} libexpat1-dev{a} libfontconfig1-dev{a} libfreetype6-dev{a} libglib2.0-dev{a} libgtk2.0-dev libice-dev{a} libjpeg62-dev{a} libmail-sendmail-perl{a} libpango1.0-dev{a} libpixman-1-dev{a} libpng12-dev{a} libpthread-stubs0{a} libpthread-stubs0-dev{a} libsm-dev{a} libsys-hostname-long-perl{a} libsysfs-dev{a} libx11-dev{a} libxau-dev{a} libxcb-render-util0-dev{a} libxcb-render0-dev{a} libxcb1-dev{a} libxcomposite-dev{a} libxcursor-dev{a} libxdamage-dev{a} libxdmcp-dev{a} libxext-dev{a} libxfixes-dev{a} libxft-dev{a} libxi-dev{a} libxinerama-dev{a} libxrandr-dev{a} libxrender-dev{a} po-debconf{a} x11proto-composite-dev{a} x11proto-core-dev{a} x11proto-damage-dev{a} x11proto-fixes-dev{a} x11proto-input-dev{a} x11proto-kb-dev{a} x11proto-randr-dev{a} x11proto-render-dev{a} x11proto-xext-dev{a} x11proto-xinerama-dev{a} xtrans-dev{a} zlib1g-dev{a} 0 пакетов обновлено, 51 установлено новых, 0 пакетов отмечено для удаления, и 0 пакетов не обновлено. Необходимо получить 11,4MБ архивов. После распаковки 39,4MБ будет занято. Хотите продолжить? Y

Проверяем. Снова запускаем./configure. И видим ниже счастье:) Команда выполнилась успешно!!!

$ ./configure ... Install Geany in: /usr/local Using GTK version: 2.16.1 Build with GTK printing support: yes Build with plugin support: yes Use virtual terminal support: yes Use (UNIX domain) socket support: yes Configuration is done OK.

make

Компилируем в бинарные файлы

Установка пакета (2 способа)

1 -й способ -стандартный (подходит для любого дистрибутива Unix). Лучше использовать во FreeBSD при установке из портов. В Ubuntu это приведет к засорению системы, так как менеджеры пакетов (apt, aptitude и т.д.) не будут видеть установленной программы. Соответственно удалять ее придется вручную. $ make install

2 -й способ - использование утилиты checkinstall # aptitude install checkinstall # man checkinstall NAME checkinstall - Track installation of local software, and produce a binary manageable with your package management software. ...

Так как сборку пакета производим под Ubuntu -нас интересуют ключи:

D Create a Debian package.

Полная последовательность команд:

$ cd /home/darkfire/deb/geany/geany-0.17 $ ./configure $ make $ sudo bash # дальнейшие команды должны выполняться от root # checkinstall -D ... ********************************************************************** Done. The new package has been installed and saved to /home/darkfire/deb/geany/geany-0.17/geany_0.17-1_i386.deb You can remove it from your system anytime using: dpkg -r geany ********************************************************************** ...

Пакет geany_0.17-1_i386.deb собран и готов к установке.

Создание пакета Eric Python IDE

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

# aptitude install bicyclerepair libqscintilla2-3 libqt3-i18n libqt4-assistant libqt4-help libqt4-webkit libqt4-xmlpatterns $ mkdir -p /home/darkfire/deb/eric4ide $ cd /home/darkfire/deb/eric4ide $ wget http://downloads.sourceforge.net/project/eric-ide/eric4/4.3.5/eric4-4.3.5.tar.gz $ wget http://downloads.sourceforge.net/project/eric-ide/eric4/4.3.5/eric4-i18n-ru-4.3.5.tar.gz?use_mirror=sunet $ tar -xzvf eric4-4.3.5.tar.gz $ tar -xzvf eric4-i18n-ru-4.3.5.tar.gz $ cd /home/darkfire/deb/eric4ide/eric4-4.3.5/ $ sudo bash # checkinstall python install.py checkinstall 1.6.1, Copyright 2002 Felipe Eduardo Sanchez Diaz Duran Эта программа распространяется на условиях GNU GPL The package documentation directory ./doc-pak does not exist. Should I create a default set of package docs? [y]: Готовится документация к пакету...OK Пожалуйста напишите описание пакета. Закончите ваше описание пустой строкой или EOF. >> Создаем пакет Eric IDE с поддержкой русского языка. >> ***************************************** **** Debian package creation selected *** ***************************************** Этот пакет был создан с использованием данных значений: 0 - Maintainer: [ root@ubuntuatom ] 1 - Summary: [ Создаем пакет Eric IDE с поддержкой русского языка. ] 2 - Name: [ eric4 ] 3 - Version: [ 4.3.5 ] 4 - Release: [ 1 ] 5 - License: [ GPL ] 6 - Group: [ checkinstall ] 7 - Architecture: [ i386 ] 8 - Source location: [ eric4-4.3.5 ] 9 - Alternate source location: 10 - Requires: 11 - Provides: [ eric4 ] Введите номер для изменения параметра или нажмите ВВОД для продолжения: ... Compiling eric/uninstall.py ... Installing eric4 ... Installation complete. ======================== Установка успешно завершена ====================== Copying documentation directory... ./ ./README-i18n.txt ./THANKS ./README grep: /var/tmp/tmp.hxkpsnHJSB/newfile: No such file or directory Some of the files created by the installation are inside the build directory: /home/darkfire/deb/eric4ide/eric4-4.3.5 You probably don"t want them to be included in the package, especially if they are inside your home directory. Do you want me to list them? [n]: Исключить их из пакета? (ответить ДА-хорошая идея) [y]: Файлы копируются во временный каталог...OK Stripping ELF binaries and libraries...OK Сжимаются страницы руководства...OK Построение списка файлов...OK Собирается Debian-пакет... Удаляются временные файлы...OK Записывается пакет с резервной копией...OK Удаляется временный каталог...OK ********************************************************************** Done. The new package has been installed and saved to /home/darkfire/deb/eric4ide/eric4-4.3.5/eric4_4.3.5-1_i386.deb You can remove it from your system anytime using: dpkg -r eric4 **********************************************************************

Устанавливаем скомпилированный пакет:

Dpkg -i eric4_4.3.5-1_i386.deb

Неудача

при запуске -возникает ошибка

# eric4 Traceback (most recent call last):

File "/usr/lib/python2.6/dist-packages/eric4/eric4.py", line 20, in from PyQt4.QtCore import QTextCodec, SIGNAL, SLOT, qWarning, \

ImportError: No module named PyQt4.QtCore

Сегодня я расскажу на абстрактном примере как правильно создать *.deb пакет для Ubuntu/Debian. Пакет мы будем делать бинарный. Пакеты, компилирующие бинарники из исходников здесь не рассматриваются: осилив изложенные ниже знания, в дальнейшем по готовым примерам можно понять суть и действовать по аналогии:)

В статье не будет никакой лишней возни «вручную»: формат пакета эволюционировал в достаточно простую, а главное - логичную структуру, и всё делается буквально на коленке, с применением пары специализированных утилит.

В качестве бонуса в конце статьи будет пример быстрого создания собственного локального репозитория: установка пакетов из репозитория позволяет автоматически отслеживать зависимости, и конечно же! - устанавливать всё одной консольной командой на нескольких машинах:)

Для тех, кто не хочет вдаваться в мощную систему установки софта в Linux, рекомендую посетить сайт проги CheckInstall : она автоматически создаёт deb-пакет из команды «make install» ;) А мы вместе с любопытными -

Источники

Информация надёргана из многих мест, но вот два основных:

• Debian.org: Debian Policy Manual - официальная
• Ubuntu Wiki: PackagingGuide/Basic

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

Подготовка

Зачем это всё?

Да, CheckInstall умеет создавать рабочий пакет, но он не поддерживает все вкусности, на которые способны deb пакеты:) А именно:

• Скрипты, выполняющиеся до, после и вместо установки пакета:)
• Автоматическое управление конфигурационными файлами: пакет не позволит затереть старые конфиги новыми без спроса
• Работа с шаблонами: возможность задавать пользователю вопросы при установке (!!!)
• Изменение файлов других пакетов

Что потребуется

Конечно, для создания полноценного пакета хватит архиваторов tar, gz, ar, но можно исключить лишнюю возню, и воспользоваться инструментами, созданными для облегчения жизни:)
Ставим:
$ sudo apt-get install dpkg debconf debhelper lintian

Что мы будем делать

Для примера будет рассмотрен некий скрипт /usr/bin/super.sh. Не важно что внутри, главное - как он появится на правильном месте:)

Подготовка папки

В домашнем каталоге (или где удобно) создаём папку, в которой будут лежать все файлы будущего пакета: mkdir ~/supersh . Далее будем называть её корень пакета .
В корне пакета создаём папку «DEBIAN» (заглавными буквами, это важно!). Эта папка содержит управляющую генерацией пакета информацию, и не копируется на диск при установке пакета.
Также корневая папка пакета содержит будущий «корень диска»: при установке пакета все файлы (кроме папки «debian») распаковываются в корень /. поэтому наш скрипт должен лежать по такому пути, относительно корня пакета: «usr/bin/super.sh»
Белым по чёрному:
mkdir -p ~/supersh/DEBIAN # управляющая папка
mkdir -p ~/supersh/usr/bin # путь к скрипту
cp super.sh ~/supersh/usr/bin/ # копируем наш скрипт в нужное место
В итоге имеем:
supersh/DEBIAN/
supersh/usr/
supersh/usr/bin/
supersh/usr/bin/super.sh

Создание пакета: DEBIAN/*

Как я уже сказал, папка DEBIAN содержит файлы, используемые при установке. Здесь я опишу (с примерами) каждый файл.
Для создания полноценного пакета достаточно контрольного файла «control», все остальные используются либо для прикрепления текстовой информации (changelog, лицензия), либо для управления расширенными возможностями установки приложений.
Из описанных ниже файлов в папке DEBIAN/* выбираем необходимые, и заполняем согласно инструкции:)
В наше примере реально используется только обязательный DEBIAN/control .

DEBIAN/control: Основная информация

control - центральный файл пакета, описывающего все основные свойства. Файл - текстовый, состоящий из пар «Атрибут: значение». Можно использовать комментарии: символ "#" в начале строки (возможность была добавлена в версии dpkg >= 1.10.11, надеяться на комментарии не стоит:).
В таблице приведены все поля, определённые для контрольного файла. Обязательные поля выделены жирным : без них пакет не будет считаться составленным верно.

Атрибут	Описание	Примеры
- основные -
Package:	Имя пакета: - только латиница, цифры, и дефис. Имя используется при установке: apt-get install	Package: supersh
Version:	Версия пакета (и проги внутри). Используется для определения «обновлять ли». Формат принят такой: <версия_программы>-<версия_пакета> . Рекомендую всегда указывать версию пакета: при изменении структуры пакета цифра увеличивается на единичку. Допустимые символы достаточно вольные: можно использовать дату и буквы. Примеры смотрите сегодня в своём репозитории:)	Version: 1.0-1 Version: 2009.12.12-1
Provides	Имя приложения (возможно, виртуальное), регистрируемое в системе в результате установки этого пакета. Используется редко: в основном, если нужно изменить имя пакета, или если более одного пакета предлагают одинаковый функционал. Например, пакеты Apache и nginx предоставляют возможность демона httpd: Provides: httpd Вы наверняка сталкивались с ошибкой при попытке установки: «is a virtual package». Это оно и есть:)	Provides: supersh
Maintainer	Имя и почта мэйнтейнера пакета: человека, который «дебианизировал» приложение. Формат произвольный, но принято имя	Maintainer: o_O Tync
Architecture	Архитектура процессора, для которой предназначен пакет. Допустимые значения: i386, amd64, all, source all используется для скриптов: они же портативные, верно? :) source используется для компилируемых пакетов с исходниками	Architecture: all
Section	Определяет задачу, для которой приложение обычно используется (группа приложений). Возможные значения: 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	Section: misc
Description	Описание пакета. Описание состоит из двух частей: короткое описание (70 символов) на той же строке, и длинное описание на последующих строках, начинающихся с пробела . В расширенном описании все переводы строки игнорируются. Для вставки \n используется одиночная точка.	Description: Short. ␣Long ␣goes here. ␣. ␣New line.
- связи и зависимости -
Depends	Список пакетов через запятую, которые требуются для установки этого пакета. После имени пакета можно в круглых скобках указать ограничение на версию, используя операторы: <<, =, >>, <=, >=. Если оператор не указан - используется >=	Depends: dpkg, libz (>= 1.2.3), jpeg (= 6b), png (< 2.0)
Pre-Depends	Список пакетов, которые требуются в процессе установки этого пакета. Эти зависимости могут потребоваться для скриптов установки пакета: например, пакет flash-installer требует wget Можно использовать ограничения на версию (см. Depends).	Pre-Depends: wget (>= 1.0)
Conflicts	Список пакетов, которые не могут быть установлены одновременно с этим. Установка не удастся, если хоть один из перечисленных пакетов уже будет установлен.	Conflicts: crapscript
Replaces	Список пакетов, файлы которых модифицируются этим пакетом. Требуется в случае создания «пакета-патча», изменяющего что-либо: в противном случае при замене файлов чужого пакета возникнет ошибка при установке. У меня, например, такой пакет патчит UT2004 и убирает звук наводящейся ракетницы:)	Replaces: ut2004
Recommends	Список пакетов, рекомендуемых к установке Эти пакеты не обязательны, но обычно используются вместе с текущим	Recommends: superplatform
Suggests	Список пакетов, предлагаемых к установке. Эти пакеты не обязательны, но с ними прога работает ещё лучше:) По идее, менеджер пакетов должен предлагать установить их.	Suggests: supersh-modules
Build-Depends	(Только для Architecture: source) Список пакетов, требуемых для компиляции исходников. То же, что и Depends, но логически отделено.	Build-Depends: cmake
- экстра -
Installed-Size	Размер файлов пакета в килобайтах. Просто цифра, округлённая до ближайшего целого. Используется менеджером пакетов для определения суммарного требуемого объёма на диске.	Installed-Size: 3
Priority	Приоритет пакета: насколько он важен в системе Возможные значения: extra, optional, standard, important, required (такие пакеты не удаляются вообще!).	Priority: optional
Esssential	Если установить этот атрибут в значение «yes», пакет нельзя будет удалить.	Esssential: yes
Origin	Строка: откуда получены программы в пакете. Обычно используется URL сайта автора, почта или имя.	Origin: brain
X-Source	Полная ссылка на *.tar.gz архив с исходниками	X-Source: ...*.tgz

Да, вот такие солидные возможности у контрольного файла:)
А в нашем примере он выглядит так:
Package: supersh
Version: 1.0-1
Section: misc
Architecture: all
Depends: bash, sed (>= 3.02-8)
Maintainer: o_O Tync
Description: Super Shell Script
␣A super example script.
␣.
␣It does nothing:)

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/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: создание пунктов меню

Хитрый файл для создания пунктов меню. У меня он так и не заработал:) Складывается ощущение, что его содержимое используется либо в необычных оконных менеджерах, либо в каком-то консольном меню… или же использовалось ранее и было забыто:)
Пример:
?package(supersh):needs="text" section="Applications/Programming" title="Super Shell Script" command="/usr/bin/super.sh"
TODO: узнать зачем нужно. Об этом написано в man5 menufile , честно говоря я не вникал:)

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

Файл /DEBIAN/menu создаёт неизвестно что и непонятно где: элементы графического меню всё равно не создаются. Поэтому будем делать правильно:)
В /usr/share/applications видим кучку *.desktop файлов: это и есть пункты меню. Они представляют собой текстовые файлы с синтаксисом наподобие ini-файла. Открываем, учимся, делаем так же и кладём получившийся *.desktop файл в usr/share/applications/ . Иконка для него должна лежать в usr/share/pixmaps .
После этого в postinst скрипт нужно добавить выполнение команды обновления меню update-menus:
if [ "$1" = "configure" ] && [ -x "`which update-menus 2>/dev/null`" ] ; then
update-menus
fi

Работа со скриптами установки пакета будет рассмотрена далее.
Спасибо Condorious за наводку:)

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

Используется для проверки целостности пакета. Важный файл.
Заполняется так (cwd=корень пакета):
$ md5deep -r usr > DEBIAN/md5sums

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

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

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

Всего можно создать до четырёх скриптов в одном пакете:

Обратите внимание, что ошибки, возникающие в этих скриптах никак не логируются : ничего интереснее кода возврата скрипта нигде не сохраняется, и логирование необходимо делать вручную! Пользователи одного моего пакета терпели неудачу при установке на Linux Mint, и не было даже возможности попросить у них лог ошибок (которого нету) чтобы выдебагать причину:)
Рекомендую использовать в начале каждого скрипта следующую болванку: она будет сохранять в syslog все возникающие ошибки.
#!/bin/bash
set -e # fail on any error
set -u # treat unset variables as errors

# ======[ Trap Errors ]======#
set -E # let shell functions inherit ERR trap

# Trap non-normal exit signals:
# 1/HUP, 2/INT, 3/QUIT, 15/TERM, ERR
trap err_handler 1 2 3 15 ERR
function err_handler {
local exit_status=${1:-$?}
logger -s -p "syslog.err" -t "ootync.deb" "supersh.deb script "$0" error code $exit_status (line $BASH_LINENO: "$BASH_COMMAND")"
exit $exit_status
}

Ваш код установочного скрипта...

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 - как и в контрольном файле, состоит из двух полей: короткое описание, и длинный текст. Первое - это заголовок «окна», второе - более развёрнутое описание того, что требуется от пользователя. Рекомендуется не использовать слов вроде «введите», а сразу суть: «Приветствие скрипта», «Точка монтирования»,…

Тип	Описание шаблона
string	Приглашение на ввод текстовой строки
password	Приглашение на ввод пароля. Для этого типа шаблона нет значения Default по понятным причинам:)
boolean	Галочка:) Имеет строковое значение «true» или «false»
select	Возможность выбора одного из нескольких вариантов. Choices: yes, no, maybe
multiselect	Возможность выбора нескольких вариантов галочками. Варианты предлагаются в дополнительном атрибуте шаблона: Choices: sex, drugs, rock-n-roll
text	Выводит на экран текст: некоторая не очень важная информация
note	Выводит на экран текст: важная информация
error	Выводит на экран текст: очень важная информация, критическая.

Для шаблонов text, note, error также нет значения Default, так как они лишь отображают информацию:)
Поиграемся с следующим шаблоном:
Template: supersh/greeting
Type: string
Description: Welcome message
␣The message you wish the script to welcome you with.
Default: Greetings, my master!

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

Это лишь работоспособные наброски. В оригинале почитать о шаблонах и работе с ними можно здесь: man 7 debconf-devel:)
Чтобы использовать шаблоны в своём скрипте настройки DEBIAN/config, необходимо сначала подключить функции debhelper:
. /usr/share/debconf/confmodule . Также этот файл нужно подключить в скрипте postinst: иначе скрипт DEBIAN/config вообще не выполнится!
Эти функции доступны в пакете debconf, не забудьте включить его в зависимости!
Примитивный пример использования. Файл DEBIAN/config
#!/bin/bash -e

# Подключение команд debconf

Case "$1" in
configure|reconfigure)
# Запрос


# Обработка ответа

greeting="$RET"
echo "$greeting" > /etc/supersh/greeting.txt
;;
*)
echo "config called with unknown argument \`$1"" >&2
exit 1
;;
esac
# Запрос
db_input medium "supersh/greeting" || true # инициализация
db_go || true # вывод запроса на экран

# Обработка ответа
db_get "supersh/greeting" # Получение значения в переменную $RET
greeting="$RET"
echo "$greeting" > /etc/supersh/greeting.txt

Здесь уже кроется неприятная засада: обратите внимание, что функции db_input передаётся приоритет диалога medium. Для debconf можно установить минимальный приоритет: диалоги с приоритетом ниже которого не отображаются, а берётся значение по умолчанию (Default шаблона)! Чтобы этого ТОЧНО не случилось - используем приоритет critical:) Кроме того, при установке из GUI порог вывода вопросов выше, и многие из них не отображаются вообще.
Возможные приоритеты: low - всегда используется default, medium - дефаулт обычно вполне подходит, high - дефаулт нежелателен, critical - внимание пользователя жизненно важно.
|| true используется чтобы скрипт не помер из-за ключика "-e" переданного bash.
В этом скрипте тоже рекомендуется использовать ту болванку для отлова ошибок, иначе с распространяемым пакетом могут возникнуть проблемы при отладке:)
Все тонкости использования debconf (функции, способы, параметры, коды ошибок) описаны в достаточно многословном мане: man debconf-devel .

И последнее: при удалении пакета командой purge - debconf должен также вычистить из своей базы сведения о пакете. Например, он сохраняет выбор пользователя при запросах db_input.
Чтобы вычистить эти данные, нужно в postinst-скрипт добавить следующее:
if [ "$1" == "purge" ] && [ -e /usr/share/debconf/confmodule ] ; then
. /usr/share/debconf/confmodule
db_purge
fi

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

Ура! Все нужные файлы созданы, лежат по нужным папочкам. Теперь пора собирать пакет:)
Первое, что нужно сделать - это рекурсивно выставить всем файлам в корне пакета пользователя и группу root:root (или другие, если потребуется). Это нужно затем, что файлы пакета упаковываются в tar.gz архив который сохраняет и права доступа к файлам, и владельца. Потому нужно выполнить:
$ sudo chown -R root:root .
Однако делать это не обязательно. Есть отличная команда fakeroot которая при создании архива подменит владельца файлос root-ом.
В нашем примере, скрипт должен иметь бит выполнимости.
Потом выходим на папку назад, чтоб было видно корневую папку пакета, и пакет создаётся лёгким пинком сам:
$ fakeroot dpkg-deb --build supersh
Созданный пакет необходимо переименовать, чтобы он соответствовал порядку именования *.deb пакетов: <имя пакета>_<версия>_<архитектура>.deb
$ mv supersh.deb supersh_1.0-1_all.deb
Всё, пакет готов!

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

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

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

$ sudo dpkg -i 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
Этот репозиторий можно также расшарить при помощи веб-сервера.

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

В корень репозитория кладём *.deb файлы для добавления, и добавляем их в компоненту soft дистрибутива karmic:
reprepro -C soft includedeb karmic *.deb
теперь пакеты доступны из менеджера пакетов:)
Удаление пакетов:
reprepro -C soft remove karmic supersh

Финиш

В статье рассмотрены материалы по созданию deb пакетов. Акцент сделан на моментах, для которых в сети нет достаточно наглядного описания. Надеюсь, что моя попытка изложить просто и понятно не провалилась:)
Домашнее задание:)) - вполне неплохо документированные вещи, которые легко найти в man"ах и статьях:

• Создание source пакетов, компилирующих исходники: на примере Zabbix об этом отлично рассказал хабраюзер mahoro в своей статье
• Debconf, debhelper в конфигурационных скриптах: читаем маны по debconf-devel и debhelper. Они также позволяют создать скелет пакета командой dh_make.
• Продвинутые способы создания документации в пакетах: файлы DEBIAN/docs, DEBIAN/manpage.*
• Создание init скриптов
• Управление заданиями cron
• Подписывание репозитория ключём gpg