Как собрать deb пакет из установленного приложения
Зачастую некоторый пакет имеется в ветках unstable и experimental, однако его нет в ветках stable/testing. Программу поставить очень хочется, а обновлять полсистемы страшновато или нежелательно.
В большинстве случаев установить пакет из unstable и experimental можно, используя пересборку пакета в своем окружении. Делается это довольно несложно, и данное руководство предназначено для того, чтобы помочь начинающему пользователю в этом вопросе. Для примера мы разберем вариант с установкой пакета fluxbox из experimental-ветки.
Установим инструменты для сборки:
Сгенерируем gpg-ключ и выполним экспорт некоторых переменных окружения, связанных с ним:
Настройка apt-get
Прежде всего, нам необходимо настроить apt-get на работу с src-репозитариями Debian. Для этого добавьте в Ваш файл /etc/apt/sources.list следующие строки:
Зеркало пакетов, разумеется, можете выбрать любое - то, которым наиболее часто пользуетесь. После изменения файла /etc/apt/sources.list сделайте традиционный
и будем считать систему настроенной для наших дальнейших действий.
Немного теории
Что представляет собой src-пакет в системе Debian?
Src-пакет для debian - это исходные тексты программы, которые любезно предоставлены автором под той или иной лицензией, дополненные несколькими скриптами (которые предоставлены сопровождающим пакета), обеспечивающими сборку пакета.
Все скрипты, файлы и т.п., относящиеся к сборке пакета в системе Debian, традиционно располагаются в подкаталоге debian/ вместе с исходными текстами.
Примечание: Некоторые включают каталог debian/ прямо в архив с исходными кодами. Это в основном касается программ разработанных специально для Debian. В таком случае вместо файлов .orig.tar.gz и .diff.gz будет один файл package-version.tar.gz.
Получение и распаковка пакета с исходными текстами
В системе, настроенной как было рекомендовано выше, данная процедура выливается в одну команду:
для нашего случая с fluxbox это будет выглядеть так:
Чтобы узнать список версий в доступных репозиториях, можно использовать команду
В результате этого действия, как видно из приведенного выше лога, были скачаны нужные файлы с зеркала (которое мы прописали в /etc/apt/sources.list) и произведена распаковка исходников и наложение патча в .diff.gz.
Данную операцию необязательно было проделывать с помощью apt-get, можно было пойти на страничку пакета, скачать файлы по ссылке Downloads (внизу страницы) и распаковать командой
Также можно использовать утилиту dget, которая скачает весь пакет и сразу распакует исходники:
Немного об устройстве каталога debian/
Все действия по сборке пакетов выполняются из каталога с исходными текстами, который получился при распаковке src-архива. В этом каталоге расположен и каталог debian/.
как видим это просто список пакетов которые необходимы нам при сборке.
Зависимости для сборки
Это может оказаться как самый простой вопрос, так и самый сложный. Ситуация состоит в следующем. Сопровождающий пакета, как правило, является человеком, хорошо разбирающимся во внутреннем устройстве Debian, поэтому сопровождающие зачастую раньше других переходят на использование testing/unstable веток. Кроме того, аплоад пакетов в Debian происходит прежде всего в unstable, а потому сопровождающий часто оттестировал сборку своего пакета только под testing/unstable. Довольно редко авторы программ указывают версионные зависимости для своих детищ, поэтому не всегда удаётся проставить правильные версии, и они могут быть как завышены, так и занижены. Выяснять, с какой версией той или иной библиотеки перестанет собираться программа занимает много времени и сил, а зачастую и не очень нужно.
Установка зависимостей для сборки
Простой случай: все получилось с первого раза
Если у Вас apt-get настроен так, как было указано выше, то в большинстве случаев установка зависимостей может быть сделана одной командой:
Для рассматриваемого нами пакета fluxbox все необходимое будет установлено без проблем, и можно переходить к разделу (ниже) Сборка пакета.
Требуемые зависимости отсутствуют в моем дистрибутиве
Сборка пакета
Простая сборка
Итак, все что необходимо нам для сборки, установлено. Осталось, собственно, собрать пакет. Для этого нам понадобится утилитка fakeroot, установите ее, если она у Вас еще не установлена.
Это приведет к тому что будет вызван редактор changelog-файла пакета. Куда вы должны вписать что-то о ваших действиях. Если, например, Вы понизили версионную зависимость, то напишите об этом. Этот шаг можно, конечно, пропустить, однако лучше все же указать, кем собран пакет и зачем. Это может пригодиться в случае, если Вы, например, захотите с кем-то поделиться результатами своего труда, а так же, если вдруг решите сообщить о каком-то баге: измененный номер версии пакета будет фигурировать в письме, написанном при помощи reportbug.
-
Это не должна быть версия, встречающаяся в официальном репозитории (чтобы не создавать путаницы)
Если вы делаете просто бэкпорт, то версия должна быть младше той версии, на основе которой собран пакет (чтобы не возникло проблем, когда этот пакет попадет в testing, затем в stable и вы попробуете сделать dist-upgrade). Добавьте строку
Исходя из этого, правильным будет добавить к версии -какаятострока1, если вы что-то существенно дорабатывали, или
какаятострока1, если делали бэкпорт.
В результате будет в родительском каталоге собран двоичный пакет, ради которого затевалась вся катавасия.
-
Вы что-то не (так) сделали на предыдущих шагах (например, понизили зависимость, а реально этого делать было нельзя);
Вернитесь на несколько шагов назад и повторите попытку.
Если есть только архив с исходниками
Итак, у нас есть только fluxbox-0.9.15.tar.bz2. Обычно выполняюncz следующие действия: Предварительно подготавливаю рабочую директорию:
Получаем файл fluxbox-0.9.15.tar.bz2. Немного забегая вперёд, обработаем файл программой gzip.
Получим fluxbox-0.9.15.tar.gz, переименуем:
(т.е. разделили имя и версию подчёркиванием и после версии добавили слово orig: fluxbox_0.9.15.orig.tar.gz) Теперь распаковываем его (но ни в коем случае не удаляем!):
Для корректной сборки нужно, чтобы корневая директория содержала не только название, но и версию! Ниже будем считать директорию
/src/fluxbox/0.9.15/fluxbox-0.9.15 корневой директорией исходников. Далее выполняем «черновую» сборку. Т.е. делаем, как обычно
(но не устанавливаем!) Если конфигурируется со всеми нужными опциями и собирается в бинарный файл, значит осталось только дебианизировать.
Если есть только deb-пакет
Распаковываем пакет в папку /tmp/program/
Чтобы распаковать информацию о пакете, нужно выполнить:
Теперь можно делать изменения. Чтобы снова собрать пакет, делаем следующее:
Дебианизация
Cмысл всей этой процедуры - создать директорию debian в корне исходников, с нужными файлами конфигурации и скриптом(ами). Для этого, в корне исходных текстов (
В таком случае советую прервать dh_make (Ctrl+C) и переименовать архив, как описано выше. Но мы с вами молодцы и всё у нас прошло без ошибок - появился каталог debian в корне исходников, посмотрев его содержимое, Вы увидите кучу файлов (расширение .ex) с примерами на все случаи жизни. Будем считать, что программа у нас простая, обычно ни один из этих файлов не нужен. Первым делом нужно добавить описание программы в файле debian/control:
без этого мы получим пустой пакет. Обычно этих настроек достаточно для сборки пакета с одной программой, которая не содержит разделяемых библиотек, т.е. только бинарник в /usr/bin и данные в /usr/share. Теперь, соберём пакет:
в директории выше, т.е. в
/src/fluxbox/0.9.15, мы получим файлы:
Установка пакета
После того, как пакет собран, его осталось установить командой:
Или включить его в состав собственного репозитария. Это уже базовые вещи в системе Debian, поэтому их описание наведено в других статьях вики.
Сборка с созданием чистых образов систем
На самом деле, для того, чтобы собрать пакет правильно, его надо собирать в минимальной системе, где стоят только build-essential и зависимости этого пакета. Тогда, во-первых, не будет никаких накладок из-за того, что у вас в системе стоят некоторые пакеты вообще неизвестно откуда и непонятно каких версий (и в итоге в зависимостях у бинарного пакета могут оказаться пакеты версий, отсутствующих в том дистрибутиве, под который вы хотите собрать пакет), а во-вторых, вы избежите накладок (крайне редких, но все же), когда установленный лишний пакет как-то (читай негативно и не всегда очевидно) влияет на сборку.
В качестве решения подойдет chroot с чистым окружением… Испугались? Все уже украдено до нас.
Сборка пакета в системе pbuilder
Довольно неплохо упрощает данный процесс интерактивная программа pbuilder. Установите пакет pbuilder, затем откройте на редактирование /etc/pbuilderrc и пропишите адрес Вашего любимого репозитория.
система готова к употреблению.
Вместо имени sarge подставьте название Вашего дистрибутива.
теперь чтобы собрать пакет для выбранного дистрибутива дайте команду:
Будут автоматически проделаны все описанные выше шаги, при этом все пакеты требуемые для сборки скачиваются и устанавливаются во временный каталог, поэтому система не "замусоривается" лишними пакетами. Правда, проблему с зависимостями для сборки всё равно придется решать, однако последовательно пройти по всем зависимостям с данным инструментом не представляет особого труда. Почитайте документацию на этот замечательный пакет и узнайте об остальных его возможностях.
Сборка пакета в системе cowbuilder
сowbuilder является из пакета cowdancer – это аналог pbuilder, только образ сборочной системы он хранит не в tar.gz а в развернутом виде, а при сборке копирует этот образ с использованием техники copy-on-write, что ускоряет сборку.
Пример конфига /etc/pbuilderrc:
Создать образ системы можно и без использования конфига:
Теперь логинимся в чистую систему:
Дальше ставим утилиты для сборки и действуем как в стандартной системе (смотреть след. раздел и начало страницы):
Виход из окружения стандартен, собраные пакеты искать в /var/cache/pbuilder.
Сборка пакета в чистом окружении
Как теперь собрать пакет в нужном окружении. Вначале из нашего каталога <имя пакета>-<версия апстрим> с измененной версией и поправленными build-depends собираем сурцовый пакет новой версии:
Переходим каталогом выше, где собрался файлик <имя пакета>_<версия>.dsc (где версия, это уже наша версия с “
backport”) и говорим
Если произошла ошибка (например из-за проблем с зависимостями), то возвращаемся к шагу 1 и исправляем ошибки. Если все прошло нормально, то собранные пакеты окажутся в каталоге /var/cache/pbuilder/results. Вот собственно и все.
Для обновления образов (особенно актуально для testing) я использую команду
Самый популярный способ распространения программ в Linux - это репозитории программного обеспечения. В репозиториях программы находятся в специальном формате. В Debian и основанных на нём дистрибутивах используется формат пакетов deb. В этих пакетах находится архив всех файлов программы, инструкции по их установке в системе для пакетного менеджера, а также другая служебная информация.
В этой статье мы рассмотрим как собрать deb пакет для своей программы без использования каких-либо сторонних инструментов. Мы не будем рассматривать подпись пакетов для репозиториев, потому что для каждого вида репозиториев команды будут отличаться.
Создание deb пакетов
Шаг 1. Подготовка
mkdir hellolosst
cd hellolosst
Затем поместите в неё файл с исходным кодом:
Для компиляции программы выполните такую команду:
gcc hellolosst.c -o hellolosst
Затем вы можете её выполнить:
Таким образом, теперь у нас есть программа, которую надо упаковать в deb пакет.
2. Создание манифеста
В каждом deb пакете содержаться не только файлы самой программы, но и файл манифеста, в котором описан пакет, его зависимости и параметры. Этот файл имеет название control и должен находится в папке DEBIAN. Для сборки пакета будем использовать папку package, чтобы файлы программы не путались с исходными файлами и те не попали в пакет. Создайте эти папку:
mkdir -p package/DEBIAN
Прежде чем вы сможете создать этот файл надо узнать несколько вещей. Первым делом надо посмотреть размер файлов программы, поскольку в данном случае файл один, достаточно посмотреть его размер:
du -k ./hellolosst
Если файлов несколько, то можно удалить исходники и посмотреть общий размер папки с файлами программы. Дальше надо понять от каких пакетов будет зависеть ваша программа. Для этого воспользуйтесь командой objdump:
objdump -p ./hellolosst | grep NEEDED
В данном случае программе необходима только libc. Чтобы посмотреть в каком пакете она находится выполните:
Пакет называется libc6. Затем создайте файл манифеста со следующим содержимым:
Это минимальный набор параметров в файле манифеста. Вот их значение:
- Package - имя пакета;
- Version - версия программы в пакете, будет использована при обновлении пакета;
- Section - категория пакета, позволяет определить зачем он нужен;
- Priority - важность пакета, для новых пакетов, которые ни с чем не конфликтуют обычно прописывают optional, кроме того доступны значения required, important или standard;
- Depends - от каких пакетов зависит ваш пакет, он не может быть установлен, пока не установлены эти пакеты;
- Recommends - необязательные пакеты, но тем не менее они обычно устанавливаются по умолчанию в apt;
- Conflicts - пакет не будет установлен, пока в системе присутствуют перечисленные здесь пакеты;
- Architecture - архитектура системы, в которой можно установить этот пакет, доступные значения: i386, amd64, all, последнее означает, что архитектура не имеет значения;
- Installed-Size - общий размер программы после установки;
- Maintainer - указывает кто собрал этот пакет и кто отвечает за его поддержку;
- Description - краткое описание пакета.
3. Расположение файлов
Манифест готов. Теперь в папке пакета надо создать структуру папок, аналог того, что есть в корневой файловой системе. В данном случае надо создать папку usr/bin и поместить туда исполняемый файл:
mkdir -p package/usr/bin
mv ./hellolosst package/usr/bin
4. Скрипты установки
Несмотря на то, что система установки пакетов очень мощная и позволяет делать многое, некоторые вещи всё же сделать нельзя. Для решения этой проблемы была предусмотрена возможность выполнять скрипты перед установкой пакета и после. Аналогично это работает для удаления пакета - перед и после. Эти скрипты называются preinst, postinst, prerm и postrm. Каждый файл просто содержит набор скриптов, которые надо выполнить. Например:
Разработчики Debian не рекомендуют использовать эти скрипты без крайней надобности, поскольку они дают вам полный контроль над системой пользователя и вы можете случайно что-то повредить. Обычно эти скрипты используются для того чтобы задавать пользователям вопросы и на основе этого генерировать конфигурационные файлы.
5. Сборка и проверка пакета
Осталось собрать настроенный пакет. Для этого используйте такую команду:
dpkg-deb --build ./package
Теперь вы знаете как как собрать deb пакет. После завершения сборки можете установить его с помощью apt:
sudo apt install
Выводы
В этой небольшой статье мы рассмотрели как выполняется создание deb пакета с помощью инструмента dpkg-deb. Как видите, всё очень просто. Вам достаточно написать манифест и расположить файлы там, где они должны быть. Мы рассмотрели здесь только самые основы. На самом деле создание пакетов намного сложнее. Существует целый набор утилит debhelpers, которые используются на различных этапах сборки и установки deb пакетов, подробнее обо всём этом вы можете прочитать в официальной документации.
Нет похожих записей
Статья распространяется под лицензией Creative Commons ShareAlike 4.0 при копировании материала ссылка на источник обязательна.
Данная инструкция является шпаргалкой по сборке пакетов для deb-систем (Debian, Ubuntu, Mint и так далее). Мы рассмотрим пример работы с исходниками nginx, а также разберем подробнее опции, которые можно задействовать при сборке. На практике, данное действие не имеет смысла, так как уже собранный nginx можно получить на сайте разработчика или в репозитории системы, но для нас важно понять процесс сборки, после чего можно будет применить данные знания для своих проектов.
Подготовка системы
Процесс сборки требует установки дополнительных компонентов, что приводит к скоплению мусора из ненужных пакетов. Рекомендуется делать сборку на отдельном компьютере или в контейнере Docker. Подробнее об установке последнего в инструкции Установка Docker на Linux.
Независимо от среды, в которой мы будем собирать пакеты, необходимо выполнить предварительные настройки.
1. Установка пакетов:
apt-get install dpkg-dev devscripts wget
2. Создание пользователя.
Делать готовые установочные сборки пакетов очень опасно от пользователя root. Если мы допустим ошибку с путями, файлы могут перетереть или удалить важные для работы директории. Стоит создать отдельного пользователя и работать под ним. Однако, если мы работаем в специальной виртуальной среде или контейнере Docker, нам это не страшно. Тогда данный пункт можно пропустить и работать из-под root.
useradd builder -m
* в данном примере мы создадим пользователя builder. Опция -m сразу создаст домашний каталог для пользователя.
Теперь заходим под данным пользователем — последующие команды мы будем выполнять от него:
3. Создадим каталог, в котором будет происходит сборка:
mkdir -p debbuild
Перейдем в debbuild:
Мы готовы к сборке.
Сборка из исходников
В нашем примере мы возьмем исходники для сборки nginx (для выполнения configure, make, make install . ) и соберем из них свой пакет для установки NGINX. Процесс будет разбит на несколько этапов:
- Предварительная настройка.
- Создание файлов с инструкциями для сборки пакета.
- Выполнение сборки и проверки.
Рассмотрим каждый из этапов подробнее.
Подготовка
Создадим каталог с названием собираемого приложения (с учетом версии):
mkdir -p nginx-1.20.1/debian
* в нем обязательно каталог debian.
Перейдем в созданный каталог:
Теперь создадим несколько важных файлов.
Создание файлов сборки (основные)
Для выполнения сборки нужно создать, минимум, 4 файла.
1. Control-файл.
Это основной файл с описанием процесса сборки. Вводим:
Пример для нашего случая:
* значения для опции Build-Depends задаются экспериментально — лучше всего попробовать сначала собрать требуемый пакет вручную, чтобы понять, какие потребуется доустановить пакеты. Рекомендуется это делать на чистой системе, чтобы не получить искаженный результат (на используемой системе уже могут быть пакеты, которых не будет на другом компьютере, где будет происходить сборка).
* более подробное описание файла control представлено ниже.
2. Файл changelog.
В данном файле описывается история изменений пакета. Также сборщик берет из этого файла номер версии и релиза.
Создаем файл командой:
* в файле указано, что первые изменения внес Dmitriy Mosk 03 августа. Для начала сборки этого будет достаточно. Описание ниже.
3. Файл rules.
Описываем правила компиляции пакета во время его сборки. Создаем файл:
* важно обратить внимание на факт, что содержимое файла может сильно отличаться в зависимости от того, что мы собираем и какой версии собираемое программное обеспечение. В данном примере мы создали файл для независимой работы — сборщик сам скачает исходник и распакует его в рабочий каталог (в данном примере, nginx). Также мне пришлось переопределить этап dh_usrlocal, так как на нем возникала ошибка, связанная с невозможностью удалить каталог командой rmdir.
* в нашей системе должен быть установлен wget, как и все остальные утилиты, которыми мы захотим воспользоваться.
* более подробное описание файла rules ниже.
4. Файл compat.
Указываем на уровень совместимости с debhelper (вспомогательный инструмент для сборки пакетов). Создаем файл:
* на момент обновления инструкции рекомендовано использовать версию не ниже 9. Сама по себе сборка без данного файла (или при указании версии ниже 9) запустится, но быстро остановится с ошибкой dh_auto_clean: Compatibility levels before 9 are deprecated (level X in use), где Х — текущий уровень совместимости.
Дополнительные файлы сборки
Данные файлы не являются обязательными. Они могут увеличить возможности собираемого пакета, а также нужны для нашего удобства.
1. Файл postinst.
Является скриптом, который будет запущен после установки пакета на целевой системе. Любые постинсталляционные настройки можно выполнить с его помощью, например:
* в данном примере мы просто создадим учетную запись dmosk. Опция set -e говорит о том, что при возникновении ошибки, необходимо сразу прервать работу скрипта.
Может быть использован более сложный сценарий с обработкой аргументов, например:
case "$1" in
configure)
systemctl is-enabled --quiet nginx && systemctl disable nginx
;;
upgrade)
systemctl is-active --quiet nginx
;;
* таким образом, при установке приложения посредством, например, команды apt-get upgrade, после инсталляции будет выполнена только команда sytemctls is-active --quiet nginx.
2. Файл postrm.
Это скрипт, который выполнится после удаления пакета:
rm -rf /var/log/app
rm -rf /opt/app/test
* в данном примере мы предположили, что после удаления нужно удалить 2 каталога /var/log/app и /opt/app/test.
3. Файл preinst.
Скрипт выполнения перед установкой пакета.
4. Файл prerm.
Скрипт выполнения перед удалением пакета.
Сборка пакета
У нас созданы все необходимые файлы, выполнены предварительные действия, и мы готовы к сборке.
Проверяем, что у нас установлены необходимые пакеты и, при необходимости, установим их:
* команда является частью пакета devscripts, который мы установили в начале инструкции. Она читает опцию Build-Depends файла control и устанавливает необходимые пакеты.
Выполним сборку командой:
debuild -us -uc -b
Если мы все сделали правильно, в конце мы увидим что-то на подобие:
W: nginx: missing-depends-line
E: nginx: no-copyright-file
E: nginx: description-starts-with-package-name
E: nginx: dir-in-usr-local usr/local/nginx/
E: nginx: dir-in-usr-local usr/local/nginx/conf/
E: nginx: file-in-usr-local usr/local/nginx/conf/fastcgi.conf
W: nginx: file-in-unusual-dir usr/local/nginx/conf/fastcgi.conf
E: nginx: file-in-usr-local usr/local/nginx/conf/fastcgi.conf.default
W: nginx: file-in-unusual-dir usr/local/nginx/conf/fastcgi.conf.default
E: nginx: file-in-usr-local usr/local/nginx/conf/fastcgi_params
W: nginx: file-in-unusual-dir usr/local/nginx/conf/fastcgi_params
E: nginx: file-in-usr-local usr/local/nginx/conf/fastcgi_params.default
W: nginx: file-in-unusual-dir usr/local/nginx/conf/fastcgi_params.default
E: nginx: file-in-usr-local usr/local/nginx/conf/koi-utf
W: nginx: file-in-unusual-dir usr/local/nginx/conf/koi-utf
E: nginx: file-in-usr-local usr/local/nginx/conf/koi-win
W: nginx: file-in-unusual-dir usr/local/nginx/conf/koi-win
E: nginx: file-in-usr-local usr/local/nginx/conf/mime.types
W: nginx: file-in-unusual-dir usr/local/nginx/conf/mime.types
E: nginx: file-in-usr-local usr/local/nginx/conf/mime.types.default
W: nginx: file-in-unusual-dir usr/local/nginx/conf/mime.types.default
E: nginx: file-in-usr-local usr/local/nginx/conf/nginx.conf
W: nginx: file-in-unusual-dir usr/local/nginx/conf/nginx.conf
E: nginx: file-in-usr-local usr/local/nginx/conf/nginx.conf.default
W: nginx: file-in-unusual-dir usr/local/nginx/conf/nginx.conf.default
E: nginx: file-in-usr-local usr/local/nginx/conf/scgi_params
W: nginx: file-in-unusual-dir usr/local/nginx/conf/scgi_params
E: nginx: file-in-usr-local usr/local/nginx/conf/scgi_params.default
W: nginx: file-in-unusual-dir usr/local/nginx/conf/scgi_params.default
E: nginx: file-in-usr-local usr/local/nginx/conf/uwsgi_params
W: nginx: file-in-unusual-dir usr/local/nginx/conf/uwsgi_params
E: nginx: file-in-usr-local usr/local/nginx/conf/uwsgi_params.default
W: nginx: file-in-unusual-dir usr/local/nginx/conf/uwsgi_params.default
E: nginx: file-in-usr-local usr/local/nginx/conf/win-utf
W: nginx: file-in-unusual-dir usr/local/nginx/conf/win-utf
E: nginx: dir-in-usr-local usr/local/nginx/html/
E: nginx: file-in-usr-local usr/local/nginx/html/50x.html
W: nginx: file-in-unusual-dir usr/local/nginx/html/50x.html
E: nginx: file-in-usr-local usr/local/nginx/html/index.html
W: nginx: file-in-unusual-dir usr/local/nginx/html/index.html
E: nginx: dir-in-usr-local usr/local/nginx/logs/
E: nginx: dir-in-usr-local usr/local/nginx/sbin/
E: nginx: file-in-usr-local usr/local/nginx/sbin/nginx
W: nginx: file-in-unusual-dir usr/local/nginx/sbin/nginx
Finished running lintian.
Пакет сформирован и должен находится в директории на уровень ниже:
Среди списка файлов мы должны увидеть пакет с нашим названием:
Описание служебных файлов
Попробуем разобраться в синтаксисе обязательных файлов, которые мы создали для выполнения сборки.
Control
Данный файл содержит основную информацию о собираемом пакете. Рассмотрим по отдельности обязательные опции и дополнительные.
Основные (без которых сборщик вернет ошибку):
Дополнительные опции файла control:
Полный перечень опций можно найти в официальном руководстве.
Rules
В данном файле мы задаем поведение при компиляции пакета. Как правило, его содержимое сводится к:
* отступы должны быть табуляциями, иначе система вернет ошибку.
. что означает, что все действия по установке пакета из исходника должны быть шаблонные.
При компиляции будет запущено три группы команд:
- debian/rules clean. Выполняет чистку каталога сборки и его подготовку.
- debian/rules build. Подготовка к сборке и сборка.
- debian/rules binary. Установка и создание бинарного пакета.
Однако, для каждого из этапов мы можем переопределять поведение и задавать настройки (с помощью приставки override_ в файле). Рассмотрим примеры некоторых этапов и настроек.
Каталог источника
Задается с помощью параметра --sourcedirectory, например:
* в данном примере мы укажем сборщику, что брать исходные файлы нужно в каталоге src (относительно рабочего каталога). При таком определении источника, не забываем заранее создать каталог (в данном примере, mkdir src).
override_dh_auto_configure
Выполняет конфигурирование. Нам может потребоваться изменить опции на свои, например:
* обратите внимание, что если у нас исходник находится в отдельном каталоге, мы должны перейти в него и сразу (&&) запустить команду для конфигурирования. Если эти команды ввести в разных строках, то мы получим ошибку — перед выполнением каждой команды сборщик возвращается в исходную директорию.
dh_auto_build
На данном этапе выполняется сборка (make). Можно перед этим процессом закачивать исходник и распаковывать его в каталог src:
* в конечном итоге, мы запускаем тот же dh_auto_build, но с передачей дополнительной опции.
dh_auto_test
Выполняем цель test файла Makefile. Иногда, в процессе сборки пакета на данном этапе возвращается ошибка, хотя сама по себе компиляция и сборка прошли корректно. В таком случае, этап можно пропустить:
* для пропуска любого из этапов просто вставляем соответствующую строку с пустым перечнем действий.
dh_auto_install
На данном этапе выполняется установка пакета (make install). Рассмотрим такой пример:
* такая настройка выполнит установку, передав команде make install дополнительный параметр PG_CONFIG=/opt/pgpro/std-11/bin/pg_config. На практике, эта опция задает путь расположения конфига postgresql pro.
dh_fixperms
Задает стандартные права на файлы. Мы же можем захотеть назначить свои или отдельного владельца, например:
* в данном примере всем файлам внутри каталога будет задан владелец пользователь nginx. Обратите внимание, что мы сначала позволяем системе выставить права по своему алгоритму (dh_fixperms), после чего выполняем свою команду.
Changelog
Файл используется системой сборки для получения номера версии пакета, его ревизии, срочности и раздела. Также в него можно заносить список изменений.
Типичный пример для файла:
gentoo (0.9.12-1) unstable; urgency=medium
Дистрибутивы, основанные на Debian – это не только отличная система управления пакетами APT, которая сама разрешает зависимости, но и удобные инструменты для создания пакетов и своих репозиториев. Если уж вы решились собрать программу из исходников, то советую ещё изучить, как дебианизировать исходники. Это отнимет чуть больше времени, чем стандартное
но зато позволит сохранить систему в чистоте. Удалить программы, установленные командой make install, можно только командой
но не все исходники это поддерживают, а что ещё чаще - исходники удаляют после установки, тогда удалить программу можно только вручную. Но чтобы это сделать, нужно точно знать что и куда установилось. А это уж точно никто не знает, кроме самих разработчиков программы (ну или тех, кто более-менее разбирался в исходниках программы).
APT не знает ничего о программах, установленных вручную. Соответственно, могут быть конфликты, или просто непонятные ошибки. Очень часто исходники по умолчанию «рассчитаны» на определённый дистрибутив, или, наоборот, рассчитаны только на установку из исходников, при этом выполняются разного рода «удобные» настройки в конфигурационных файлах. Так, например, очень любят прописывать mime-типы. Но проблема в том, что переводы разные бывают и в Nautilus может выскочить ошибкаи документ не будет открываться. Таких «недочётов» может быть очень много. А теперь, если представить что это удалить нельзя, поскольку пользователь не запоминал что и куда поставилось, наступает паника и как результат - переустановка.
Но как быть, если программу хочется поставить, а версия в deb-пакете устарела, или такой вообще нет? Использовать программу checkinstall . Она собирает всё в один пакет. К сожалению, она позволяет решить только вопрос с удалением программы. И даже если APT будет знать, что программа установлена, он в лучшем случае сообщит, что есть конфликт файлов,Чаще всего такие случаи очень корректно разрешаются путём удаления конфликтного пакета. Но на разбор ситуации уйдёт некоторое время.
Cобрать нормальный пакет, как это делают мантейнеры. В котором будет корректная версия, зависимости и расположение файлов будет соответствовать политике дистрибутива. Вижу вам всё ещё интересно . Это радует.Возможны следующие случаи сборки пакетов:
исходники или бинарные файлы берутся:
из репозитория другого выпуска Ubuntu, из PPA или из Debian; берётся из репозитория Ubuntu, из PPA или из Debian: ни в репозитории Ubuntu текущего выпуска, ни в PPA нет нужной версии программы; доступная версия программы по каким-либо причинам не устраивает (не устраивает код или данные программы, параметры конфигурации или управляющая информация пакета); Дано: некий исходник gcoolprog-0.5.3.tar.bz2. Нужно из него собрать пакет. Решение: ниже идёт вариант, как я обычно поступаю в таком случае. Первым делом смотрю, нет ли deb-пакета той же версии, но допустим под Debian. Если есть делаю так: есть нужная версия пакета в репозитории debian или в будущем релизе Ununtu Если нет той же версии, но есть предыдущей. Тут можно сказать как повезёт, если изменения в исходниках не коснулись положения файлов, то скорее всего дебианизация от старого пакета подойдёт, нужно лишь сменить версию. Теперь вариант в репозитории есть пакет предыдущей версии. Ну и самый страшный случай - нигде никаких deb-пакетов нет, только tar.gz и rpm. Ни в коем случае не использовать rpm! Делаем по первому варианту.Что необходимо
Полное Руководство начинающего разработчика Debian доступно тут.
К сожалению, на русском, информация немного устарела, свежая инструкция доступна на английском. Но принципы не изменились, поэтому если интересны детали лучше прочитать руководство от и до.
Нам понадобятся как минимум программы, устанавливаемые командой
Можно так же autobook - это документация по утилитам GNU Autoconf , Automake , и Libtool . Ну и конечно то, что требуют сами исходные коды для корректной сборки.
Создание ключа шифрования
Этот шаг не обязателен, его можно пропустить.
Чтобы создать ключ, зайдите в Приложения → Стандартные → Пароли и ключи шифрования. В открывшемся окне, в меню Ключ → Новый ключ, выбираем ключ pgp. Заполняем поля Полное имя и Электронный адрес.
В мире свободного программного обеспечения, для предотвращения «краж» или «подделок», принято подписывать свои «ценные» вещи электронным ключом, открытая часть которого хранится на общедоступных серверах и позволяет другим пользователям легко выяснить подлинность и целостность той или иной вещи.
Поэтому отнеситесь к созданию ключа очень ответственно.
Никто вас не заставляет вписывать сюда реальные имя и фамилию, или ещё какие-нибудь личные данные, но если вас не разыскивает интерпол - думаю указать фамилию и имя будет верным решением, хотя можно и просто свой ник В общем, решайте сами. А вот почтовый адрес укажите реальный, и который вы не поменяете.
Хотя последняя версия программы seahorse имеет демон, который автоматически запускается в сеансе GNOME, и умеет «запоминать пароль» на время сеанса, но пока не все программы умеют с ней работать.
Итак, вы создали ключ - теперь его можно будет использовать при создании пакетов.
Для этого, в файл
/.bashrc, или в другой стартовый скрипт, вашего любимого шелла (для zsh
/.zshrc), нужно вписать переменные
На основании e-mail будет искаться ключ в pgp, при подписи пакета.
Нужно завершить сеанс и зайти заново, чтобы изменения вступили в силу.
Помните, что если вы бэкпортируете пакет, дебианизированный не вами, обязательно нужно изменить версию командой
для того, чтобы в изменения вписался ваш e-mail. А для того, чтобы ваш открытый ключ попал на сервер, необходимо в настройках «seahorse → Пароли и ключи шифрования», настроить соединение с сервером публичных ключей.
Для этого, в меню Правка→Параметры на закладке Публикация ключей необходимо поставить галку Публиковать ключи….
Теперь можно выбрать ключ и в меню по правой кнопке выбрать Синхронизировать и опубликовать ключи.
Дебианизация недоступна
Итак, у нас есть только gcoolprog-0.5.3.tar.gz.
Обычно я выполняю следующие действия:
Предварительно подготавливаю рабочую директорию
Получаем файл gcoolprog-0.5.3.tar.gz. Распакуем его перейдем в полученный каталог:
Для корректной сборки нужно, чтобы корневая директория содержала не только название, но и версию!Ниже будем считать директорию
/src/gcoolprog/0.5.3/gcoolprog-0.5.3 корневой директорией исходников.
Далее выполняем «черновую» сборку. Т.е. сконфигурируем и соберем приложение, без его установки:
Если команда выполнилась успешно, то осталось только дебианизировать.
Дебианизация
Ничего страшного в этом нет, как я уже говорил есть скрипты, которые сильно упрощают этот процесс.
Вообще смысл всей этой процедуры - создать директорию debian в корне исходников, с нужными файлами конфигурации и скриптом(ами).
Для этого, в корне исходных текстов, выполним
На что мы должны получить следующий диалог
Тут мы указываем сформировать пакет, для одиночного бинарного файла.
Но мы с вами молодцы и всё у нас прошло без ошибок - появился каталог debian в корне исходников, посмотрев его содержимое, Вы увидите кучу файлов (расширение .ex) с примерами на все случаи жизни.
Будем считать, что программа у нас простая – обычно ни один из этих файлов не нужен.
Первым делом, нужно добавить описание программы в файле debian/control
без этого мы получим пустой пакет.
Иногда debian/rules содержит лишь:
Что приемлемо с использованием debhelper.
Этих настроек будет достаточно для сборки пакета с одной программой, которая не содержит разделяемых библиотек, т.е. только бинарник в /usr/bin и данные в /usr/share.
Сборка пакета
Теперь, соберём пакет:
В директории выше, т.е. в
/src/gcoolprog/0.5.3, мы получим файлы
Вот теперь мы можем установить пакет
Дебианизация берётся из репозитория Ubuntu, из PPA или из Debian
Дебианизация берётся из другой версии программы
Как я уже сказал, возможно нам повезёт и достаточно будет только сменить версию. Но не будем гадать.
Ниже я не буду комментировать то, что описано в предыдущем решении.
Предварительно подготовим рабочую директорию
получаем файл gcoolprog-0.5.3.tar.bz2
теперь распаковываем его
копируем каталог gcoolprog-0.5.1/debian в директорию
дальше нам нужно изменить версию командой
этой командой изменяется файл debian/changelog например увидим
но поскольку у нас версия 0.5.3, то нужно изменить значения на
сохраните изменения. Теперь можно выполнить команду сборки в пакет.
Дебианизация берётся из текущей версии программы
Дебианизация берётся не из репозитория текущего выпуска Ubuntu
Предварительно подготовим рабочую директорию
теперь скачиваем три файла
или тоже самое, но одной командой
из пакета devscripts
затем распакуем командой
получим каталог gcoolprog-0.5.3.Перейдём в него и сменим версию:
теперь можно собирать пакет
Дебианизация берётся из репозитория текущего выпуска Ubuntu
В случае, когда для нужной версии программы имеется пакет в репозитории текущего выпуска Ubuntu, но он по каким-либо причинам не устраивает и в его исходники нужно внести изменения (например, применить какой-нибудь патч) и пересобрать, основываясь на уже имеющейся в пакете дебианизации, можно поступить следующим образом.
Для сборки понадобятся следующие пакеты: build-essential devscripts fakeroot. Потребуются также пакеты для разработки, мы их установим в дальнейшем.
apt-get source скачивает исходники из репозитория Ubuntu в текущую директорию. Многие пакеты в репозитории имеют общие друг с другом исходники, поэтому кроме исходников выбранного пакета могут скачаться и исходники других пакетов (общие для нескольких пакетов исходники).
Далее вносим изменения в исходники и собираем из них обратно пакеты.
Устанавливаем необходимые для сборки пакеты для разработки:
Ниже идёт пример как можно поступить в случае, если доступен только deb-пакет и нет его дебианизированных исходников.
Для начала советую прочитать это. И это. Тут полная документация на русском.Предположим, что работаем в каталоге
/tmp. Создадим подкаталог
/tmp/someprog, чтобы распаковать файлы какого-нибудь пакета, нужно выполнить
Для того, чтобы извлечь контрольную информацию, выполним
ну а теперь, чтобы всё это собрать обратно в пакет, нужно выполнить
/tmp/someprog/DEBIAN содержатся файлы, описывающие, что это за пакет, от чего он зависит, и контрольные суммы файлов, находящихся в нём. Для того, чтобы собрать свой пакет, нужно поместить файлы в каталоге
/tmp/someprog так, как будто это корневой каталог.То есть, если нужно, чтобы файл установился в /usr/bin,нужно его поместить в каталог
/tmp/someprog/usr/bin, ну и, соответственно, если что-то должно лежать в /etc, то в
/tmp/someprog/etc и т.д.
/tmp/someprog создать каталог DEBIAN, обязательно большими буквами, и в нём файл
/tmp/someprog/DEBIAN/control, в этом файле описывается название пакета, его зависимости и описание, формат очень простой. Например:
Ну а теперь собрать:
Читайте также: