Go прекрасный язык. Одна из его супер-сил - это возможность собирать все в один бинарник. А это очень удобно, вы можете везде таскать этот файл и использовать на любой машине. Но хочется иметь возможность устанавливать нашу программу простым способом.
С помощью deb пакетов довольно просто можно организовать деплой на ваши сервера. При этом у вас будет версионирование и все такое. Я чаще всего использую ubuntu, поэтому речь будет именно о deb пакетах, которые можно установить/удалить с помощью утилит apt .
Что же нужно сделать, для создания своего репозитория с пакетами? Можно воспользоваться тем же launchpad.net , например. Но, последнее время, он не очень развивается и выглядит ненадежно. К тому же, его удобно использовать для своих не коммерческих разработок, но использовать его для дистрибуции корпоративного ПО будет проблематично.
Подойдем к проблеме с другой стороны. Во первых, нам нужно собирать deb пакеты, а это очень просто сделать самим с помощью утилиты dpkg-deb . Во-вторых, нам нужно где-то эти пакеты размещать, и для этого мы воспользуемся супер простым
Сборка пакетов
Для всех своих проектов я использую . Структура проекта выглядит примерно так:
Project/ |- bin/ | |- project |- src/ | |- github.com/ | |- 4gophers/ | |- project/ | |- main.go |- vendor/
Когда я запускаю gb build , то все бинарники собираются в папке bin . Таким образом, все что нам нужно - это просто добавить спецификацию нашего будущего deb пакета прям в папку с проектом:
Mkdir project/DEBIAN touch project/DEBIAN/control
В результате будет такая структура:
Project/ |- DEBIAN/ | |- control |- bin/ | |- project |- src/ |- vendor/
В файле control нужно указать информацию о нашем пакете. Не забывайте про пустую последнюю строку:
Package: project
Priority: optional
Section: devel
Installed-Size: 100
Maintainer: Ivan Ivanov
- Package - имя вашего пакета
- Priority - приоритет пакета (optional, extra, standard, important, required) для обычных программ лучше ставить optional
- 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)
- Installed-Size - размер файлов пакета в килобайтах
- Maintainer - имя и email создателя пакета
- Architecture - архитектура процессора, для которой предназначен пакет (i386, amd64, all, source, all)
- Version - версия пакета
- Depends - в данном поле необходимо указать имена пакетов, от которых зависит ваш пакет (например, библиотеки)
- Description - в первой строке пишем короткое описание пакета, в остальных более подробно
Все что находится в папке project попадет в пакет. И папка bin тоже. В этой папке лежит наш бинарный файл, который нужно установить. Чтобы ваши файлы оказались в нужной директории на компьютере пользователя, нужно создать соответствующую структуру каталогов внутри вашей папки с проектом.
Стоит отметить, что такой подход к созданию deb пакетов не самый правильный. Конечно, в нашем случае мы осознанно идем на этот шаг, но вам нужно понимать, что в deb пакет попадет все содержимое папки project , в том числе папки src , vendor и так далее. Конечно, можно скопировать файлы в другую папку, и даже написать скрипт для этого, но все уже придумано до нас. Более правильный способ - это использовать утилиты dh_make и dpkg-buildpackage .
Теперь можно собирать пакет. Для этого на уровень выше выполним команду:
Dpkg-deb -z8 -Zgzip --build project
На уровень выше будет создан файл project.deb , который можно устанавливать с помощью команды:
Sudo dpkg -i project.deb
Свой репозиторий пакетов
Теперь переходим к самому интересному. Как же нам распространять наши пакеты? Запустим свой сервер репозиториев, конечно же. А для этого воспользуемся сервером apt репозиториев deb-simple .
Это действительно простой сервер, который устанавливается всего одной командой:
Go get github.com/esell/deb-simple
Если go не установлен на той машине, где вы собираетесь запустить сервер с репозиториями, то вы можете собрать бинарник локально и просто скопировать его. Кроме этого, можно использовать docker.
Затем нужно запустить сервер. Это можно сделать с помощью docker, но мне больше нравится использовать supervisord . Вот пример моей конфигурации сервиса:
Command=/home/user/go1.5/bin/deb-simple directory=/home/user/deb-simple/ autorestart=true stdout_logfile=none
Тут важно указать путь к бинарнику(command) и рабочую папку(directory), в которой мы разместим наш конфиг.
Сервер deb-simple поддерживает https, но пока нам это не нужно. Для репозиториев нужно создать папку repo . Наш конфиг conf.json будет выглядит так:
{ "listenPort" : "9090", "rootRepoPath" : "/home/user/deb-simple/repo", "supportedArch" : ["all","i386","amd64"], "enableSSL" : false, "SSLcert" : "server.crt", "SSLkey" : "server.key" }
Чтобы загрузить пакет в свой репозиторий, нужно воспользоваться HTTP API самого сервиса:
Curl -XPOST "http://localhost:9090/upload?arch=amd64" -F "[email protected]"
Точно так же для удаления:
Curl -XDELETE "http://localhost:9090/delete" -d "{"filename":"project.deb","arch":"amd64"}"
Нам осталось добавить наш сервер репозиториев к списку в /etc/apt/source.list.d/ . Можно создать отдельный файл с содержимым:
Deb http://my-hostname:9090/ stable main
Теперь запускайте sudo apt-get update и устанавливайте свои программы сколько душе угодно.
→ Инструкция по сборке 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
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 . Сборка пакета .
Поднимаемся на один уровень с корневой папкой пакета и выполняем сборку.
Автор: Michael Reed
Дата публикации: 4 января 2014 г.
Перевод: Н.Ромоданов
Дата перевода: июнь 2014 г.
Мы расскажем вам, как создавать два наиболее распространенных типа пакетов Linux для распространения программного обеспечения, и вы сможете сами распространять свои собственные пакеты.
Мы собираемся провести вас через процесс создания пакетов программ для двух самых популярных систем пакетов DEB и RPM. Вы можете использовать эти методы, чтобы создавать пакеты вашего собственного программного обеспечение или даже сопровождать пакеты для того программного обеспечения, которое, как вы считаете, остается незамеченным.
Мы начнем с руководство по созданию файлов DEB ((.deb) для дистрибутивов, производных от Debian - для этого мы качестве нашей базы используем Xubuntu. После этого мы подробно опишем методы, необходимые для создания пакетов RPM для использования в дистрибутивах, производных от Red Hat, и для этого мы будем использовать Fedora. Часто можно создать пакет на одном дистрибутиве, а затем установить его на родственном дистрибутиве (например, Ubuntu>Debian), но если это важно, то вам, может быть, стоит попробовать это самостоятельно.
Что касается программы, мы собираемся в качестве примера пакета, собираемого из исходного кода, использовать легковесный веб-браузер Dillo. Когда сборка выполняется из исходных текстов, в случае, если сборка не идет так, как надо, вы можете, как и обычно, поискать решения в сети интернете. Например, в случае Dillo 3.0.3, нам из-за недосмотра в архиве исходного кода пришлось для того, чтобы команды работали, перед командами сборки добавить "LIBS =-lX11" .
Сборка происходит в командной строке
Ресурсы
Инсталляция (или виртуальная машина) Ubuntu и Fedora
Пошаговое описание
Шаг 01: Использование виртуальной машины
Использование средств виртуализации, таких как VirtualBox или Vmware, часто является лучшим подходом к созданию пакетов для других систем. С одной стороны, этот подход позволяет поддерживать сравнительно чистую базовую инсталляцию, сравнимой с настройками, с которыми вероятно, будут работать другие. Это также означает, что вы, используя различные дистрибутивы, можете получить коллекцию целевых систем. Кроме того, большинство средств виртуализации позволяют эмулировать различные архитектуры, и, следовательно, на 32-разрядной платформе можно запускать 64-разрядные ОС, хотя будет страдать производительность.
Шаг 02: Начинаем с нуля
Если в Ubuntu или Fedora что-то идет не так, то можно совершенно безопасно просто удалить исходный каталог и начать все заново. Обратите внимание, что инструментальные средства Debian изменяют исходный архив, так что вам придется начать с новой копии.
Часть 1: Debian
Шаг 03: Установите среду сборки
Мы начнем с установки большей части инструментальных средств, которые нам нужны для создания программ из исходных кодов. Наберите:
$ sudo apt-get install build-essential autoconf automake autotools-dev
Теперь мы должны установить инструменты, которые используются для работы с пакетами DEB. Сделайте это с помощью следующей команды...
$ sudo apt-get install dh-make debhelper devscripts fakeroot xutils lintian pbuilder
Шаг 04: Создайте ключ GPG
Если вы еще в прошлом не создали открытый ключ GPG, его необходимо создать прямо сейчас для того, чтобы можно было подписать пакеты. Вначале вводите текст gpg –gen-key. Выберите значения, устанавливаемые по умолчанию, и при запросе введите свое настоящее имя и контактные данные. Аккуратно запишите все данные, поскольку позднее нам в конфигурационном файле потребуется их точное соответствие. После этого наберите команду ls ~/.gnupg для того, чтобы убедиться, что новый ключ существует (это файл имя_фамилия.gpg). Из него создайте открытый ключ:
Gpg -a --output ~/.gnupg/.gpg --export "[ваше имя]"
Импортируйте его с помощью:
Gpg --import ~/.gnupg/.gpg
Шаг 05: Скачайте пакет
В этом примере мы собираемся скачать и собрать самую последнюю версию веб-браузера Dillo. Перейдите на сайт Dillo (www.dillo.org) и загрузить самый свежий архив.tar.bz. С помощью команды mkdir ~/srcand создайте каталог для исходного кода и переместите в него архив.
Шаг 06: Распакуйте архив
Распакуйте архив с помощью команды tar -xjvf [имя архива].tar.bz2. Обратите внимание, что соблюдение договоренностей об именовании каталога (имяпакета-версия) является важным для наших целей, и, к счастью, пакет Dillo соответствует им. Также важно, чтобы архив с исходным кодом находится на один уровень выше каталога с исходным кодом.
Шаг 07: Настраиваем под Debian
Переместите в только что распакованный каталог скрипт dh_make, который позаботится о большей части работы — добавит конфигурационный файл и создаст структуру каталогов, и который входит в состав интруменртария разработчика, который мы добавили ранее.
Dh_make -e -c licence -f ../
В нашем примере, командная строка тбудет выглядеть следующим образом:
Dh_make -c gpl3 -e [email protected] -f ../dillo-3.0.3.tar.bz2
При появлении запроса выберите один двоичный файл. Скрипт-помощник скрипт должен в каталоге с исходным кодом создать каталог с именем Debian.
Шаг 08: Откройте управляющий файл
Откройте в текстовом редакторе управляющий файл в подкаталоге Debian. Заполните раздел «Домашняя страница» (используйте Google для заполнения списка разделов программ Debian) и поля описания этого файла.
Шаг 09: Изучите имеющиеся зависимости
Вы можете изучить, какие зависимости необходимы для запуска программы, поставляемой в виде пакета. Перейдите в каталог с исходными кодами и наберите в терминале команду dpkg-depcheck -d ./configure. Если так сделать, то будут выданы ошибки, указывающие какой отсутствует пакет, необходимый для сборки программы (поставляемой отдельно). Вы можете открыть этот пакет, набрав sudo apt-get build-dep [имя пакета], и это должно помочь, если в репозитарии дистрибутива этот пакет поддерживается. Если он не поддерживается, то вам придется неоднократно запустить команду dpkg-depcheck -d ./configur и добавлять пакеты вручную, набирая команду рsudo apt-get install [имя пакета].
Шаг 10: Добавьте зависимости в управляющий файл
Когда все действия из предыдущего шага будут завершены, у вас должен быть список всех необходимых пакетов. Добавьте этот список зависимостей в раздел depends: управляющего файла. Элемент в списке должны быть разделены запятой и пробелом.
Попробуйте выполнить этот шаг настолько полно, насколько вы сможете, и не пропускайте его. Source: - это обычно главная страница проекта. В разделе Files: * замените информацию об авторских правах именами авторов проекта. Пример заполнения вы можете увидеть в разделе Files: debian/*, в который должна быть занесена соответствующая информация. Возможно, вам придется немного побыть детективом, чтобы найти необходимую вам информацию. Ищите в каталоге с исходными кодами файлы, такие как AUTHORS и COPYING.
Шаг 12: Отредактируйте файл журнала изменений
Откройте файл журнала изменений и убедитесь, что имя и адрес электронной почты совпадают с теми, которые вы ввели при создании ключа GPG. Обычно скрипт-помощник может добавить в файл имя пользователя, а не ваше настоящее имя. Как с файлом авторских прав, не пропускайте этот раздел, поскольку из-за этого процесс создания пакета может остановиться или может быть создан неправильный пакет.
Шаг 13: Создайте пакет
Если все настроено правильно, мы можем, наконец, собрать пакет DEB. Перейдите в каталог с исходным кодом и для того, чтобы собрать пакет, который будет помещен в каталог ~/src/, наберите команду dpkg-buildpackage -b. Например, создайте пакет с помощью команды dpkg -I [пакет]. Для того, чтобы проверить на соответствие политики Debian, с помощью команды lintian [пакет] запустите программу Lintian. Обратите внимание, что этот инструмент, как известно, строгий, и ваше дело решать, допустимы ли для вас некоторые незначительные предупреждения о несоблюдения. Наконец, установите пакт с помощью команды sudo dpgk -i [пакет].
Часть 2: Создание пакетов RPM в Fedora
Шаг 14: Откройте управляющий файл
Перейдите в режим пользователя root, набрав для этого su. Начните с инсталляционной группы Development Tools (Инструменты разработки) в yum, а затем с помощью yum установите упаковщик gcc-c++ fedora-. Наберите команду usermod -a -G mock для того, чтобы добавить вашего пользователя в группу mock. Это позволяет нам выполнять процедуру сборки без необходимости перехода в роль пользователя root.
Шаг 15: Создайте среду сборки
Нажмите Ctrl + D для того, чтобы выйти из роли root. Введите rpmdev-setuptree для того, чтобы создать дерево каталогов (под ~/rpmbuild), которое нам необходимо.
Шаг 16: Скачайте архив и переместите его в нужное место
Скачайте пакет Dillo с вебсайта Dillo и переместите архив в соответствующий каталог — наберите команду mv [имя архива] ~/rpmbuild/SOURCES.
Шаг 17: Создайте файл.spec
Дистрибутивы, созданные на основе Red Hat, такие как Fedora, используют файлы.spec для задания процесса сборки. Перейдите в каталог, в котором находятся такие файлы, с помощью команды cd ~/rpmbuild/SPECS/andcreateablank.spec и создайте пустой файл.spec с помощью команды rpmdev-newspec dillo.
Шаг 18: Отредактируйте файл.spec
Наберите команду gedit dillo.spec. Заполните поля Version (Версия), Summary (Краткое содержание) Licence (Лицензия) (в данном случае — GPLv3+).В URL указывается домашняя страница проекта; в Source0 указывается адрес исходного кода. Укажите комментарии в полях BuildRequires (Требования к сборке) и Requires (Требования). Добавьте полное описание в область %description.
Шаг 19: Выполните сборку исходного кода
Если пакет вообще поддерживается в системе, запустите команду yum-builddep [имя пакета]. В противном случае, вам придется повторять команду сборки для того, чтобы получать сообщения об ошибках, или поискать документацию в архиве с исходным кодом. В каталоге SPEC наберите команду rpmbuild -ba[название пакета].spec. Если эта сборка завершится неудачно и будут выданы сообщения о дополнительных не распакованных файлах, выделите и скопируйте этот список файлов в раздел %files файла.spec и повторите команду сборки. Теперь пакет будет находиться в каталоге RPMS. Наберите команду rpm -ivh [пакет] для того, чтобы его установить. Наберите команду rpm -qa | grep [пакет] для того, чтобы убедиться, что он установлен.
Зачастую некоторый пакет имеется в ветках unstable и experimental , однако его нет в ветках stable /testing . Программу поставить очень хочется, а обновлять полсистемы страшновато или нежелательно.
Для таких случаев есть замечательный ресурс backports.org , однако его использование во многом похоже на прямое использование веток unstable и иногда доставляет бОльшие проблемы из-за периодически возникающих конфликтов между backports и unstable.
В большинстве случаев установить пакет из unstable и experimental можно, используя пересборку пакета в своем окружении. Делается это довольно несложно, и данное руководство предназначено для того, чтобы помочь начинающему пользователю в этом вопросе. Для примера мы разберем вариант с установкой пакета fluxbox из experimental -ветки.
Установим инструменты для сборки:
#aptitude install devscriptsGpg-ключ и выполним экспорт некоторых переменных окружения, связанных с ним:
export [email protected] export DEBFULLNAME="yourfullname" export [email protected]Настройка apt-get
Прежде всего, нам необходимо настроить apt-get на работу с src-репозитариями Debian. Для этого добавьте в Ваш файл /etc/apt/sources.list следующие строки:
deb-src http://ftp.debian.org/debian testing main contrib non-free deb-src http://ftp.debian.org/debian sid main contrib non-free deb-src http://ftp.debian.org/debian experimental main contrib non-freeЗеркало пакетов, разумеется, можете выбрать любое - то, которым наиболее часто пользуетесь. После изменения файла /etc/apt/sources.list сделайте традиционный
#apt-get updateНемного теории
Что представляет собой src-пакет в системе Debian?
Src-пакет для debian - это исходные тексты программы, которые любезно предоставлены автором под той или иной лицензией, дополненные несколькими скриптами (которые предоставлены сопровождающим пакета), обеспечивающими сборку пакета.
Все скрипты, файлы и т.п., относящиеся к сборке пакета в системе Debian, традиционно располагаются в подкаталоге debian/ вместе с исходными текстами.
Src-пакет Debian обычно состоит из нескольких файлов:
package-version.dsc - текстовый файл, включающий в себя перечень остальных необходимых файлов;
package-version.orig.tar.gz - архив с исходными текстами программы;
package-version.diff.gz - патч на архив с исходными текстами программы, добавляющий в них вышеупомянутый каталог debian/, а так же, возможно, содержащий исправления внесенные в исходные тексты сопровождающим.
Примечание : Некоторые включают каталог debian/ прямо в архив с исходными кодами. Это в основном касается программ разработанных специально для Debian. В таком случае вместо файлов .orig.tar.gz и .diff.gz будет один файл package-version.tar.gz .
Получение и распаковка пакета с исходными текстами
$ apt-get source packageдля нашего случая с fluxbox это будет выглядеть так:
$ apt-get source fluxbox Чтение списков пакетов... Готово Построение дерева зависимостей... Готово Нужно загрузить 1033kB архивов с исходными текстами. Получено:1 http://ftp.debian.org experimental/main fluxbox 0.9.15.1+1.0rc2-1 (dsc) Получено:2 http://ftp.debian.org experimental/main fluxbox 0.9.15.1+1.0rc2-1 (tar) Получено:3 http://ftp.debian.org experimental/main fluxbox 0.9.15.1+1.0rc2-1 (diff) Получено 1033kB за 1m38s (10,5kB/c) gpg: Signature made Втр 04 Июл 2006 17:05:39 MSD using DSA key ID E160649A gpg: Can"t check signature: public key not found dpkg-source: extracting fluxbox in fluxbox-0.9.15.1+1.0rc2 dpkg-source: unpacking fluxbox_0.9.15.1+1.0rc2.orig.tar.gz dpkg-source: applying ./fluxbox_0.9.15.1+1.0rc2-1.diff.gzЧтобы узнать список версий в доступных репозиториях, можно использовать команду
$ apt-cache policy <имя пакета>В результате этого действия, как видно из приведенного выше лога, были скачаны нужные файлы с зеркала (которое мы прописали в /etc/apt/sources.list ) и произведена распаковка исходников и наложение патча в .diff.gz .
Данную операцию необязательно было проделывать с помощью apt-get , можно было пойти на страничку пакета , скачать файлы по ссылке Downloads (внизу страницы) и распаковать командой
$ dpkg-source -x fluxbox_0.9.15.1+1.0rc2-1.dscТакже можно использовать утилиту dget, которая скачает весь пакет и сразу распакует исходники:
dget www.path.to/fluxbox_0.9.15.1+1.0rc2-1.dscНемного об устройстве каталога debian/
Все действия по сборке пакетов выполняются из каталога с исходными текстами, который получился при распаковке src-архива. В этом каталоге расположен и каталог debian/.
В данном каталоге нас прежде всего будут интересовать два файла:
debian/rules - этот скрипт осуществляет собственно сборку пакета (и представляет собой обычный Makefile);
debian/control - этот текстовый файл снабдит нас некоторой информацией, которая нам понадобится ниже;
Прежде всего в последнем файле нас интересует одна строка, для нашего пакета fluxbox она выглядит так:
Build-Depends: libx11-dev, libxext-dev, libxft-dev, libxinerama-dev, libxpm-dev, libxrandr-dev, x-dev, libxt-dev, debhelper (>=4.1.0), libxft-dev, libx11-dev, libxext-dev, libxft-dev, libxinerama-dev, libxpm-dev, libxrandr-dev, x-dev, libimlib2-dev, libgtk2.0-dev, cdbs
как видим это просто список пакетов которые необходимы нам при сборке.
Зависимости для сборки
Это может оказаться как самый простой вопрос, так и самый сложный. Ситуация состоит в следующем. Сопровождающий пакета, как правило, является человеком, хорошо разбирающимся во внутреннем устройстве Debian, поэтому сопровождающие зачастую раньше других переходят на использование testing/unstable веток. Кроме того, аплоад пакетов в Debian происходит прежде всего в unstable, а потому сопровождающий часто оттестировал сборку своего пакета только под testing/unstable. Довольно редко авторы программ указывают версионные зависимости для своих детищ, поэтому не всегда удаётся проставить правильные версии, и они могут быть как завышены, так и занижены. Выяснять, с какой версией той или иной библиотеки перестанет собираться программа занимает много времени и сил, а зачастую и не очень нужно.
Установка зависимостей для сборки
Простой случай: все получилось с первого раза
Если у Вас apt-get настроен так, как было указано выше, то в большинстве случаев установка зависимостей может быть сделана одной командой:
# apt-get build-dep fluxboxДля рассматриваемого нами пакета fluxbox все необходимое будет установлено без проблем, и можно переходить к разделу (ниже) Сборка пакета .
Требуемые зависимости отсутствуют в моем дистрибутиве
Здесь возможны два варианта.
Вариант, дающий 100%-й результат, но, возможно, требующий проделать больше работы: просматриваем строку Build-Depends , о которой речь шла выше, и смотрим, какие библиотеки или утилиты отсутствуют в нашем дистрибутиве. Как правило, их перечень не такой большой чтобы испугать настойчивого человека (одна-две). Собираем эти библиотеки или утилиты по этому хауту (рекурсивно;)).
В случае если в строке Build-Depends указана какая-то отсутствующая в нашем дистрибутиве версия пакета, то можно попробовать понизить требования сопровождающего, отредактировав файл debian/control . Попробуйте уменьшить номер версии требуемой библиотеки или утилиты, указанный сопровождающим, на тот что у Вас имеется. Перед тем как двигаться по этой пути, проглядите каталог с исходными текстами на наличие файлов INSTALL или README. В этих файлах авторы программы иногда описывают зависимости своего детища и если уж автор программы указал версионную зависимость, то скорее всего попытка ее понизить ни к чему не приведет.
Для того чтобы узнать, что еще не установлено для сборки пакета, запустите утилиту dpkg-checkbuilddeps в каталоге с исходными текстами. Эта утилита выведет список того что требуется для сборки, но еще не установлено в Вашей системе. Для перехода к следующему шагу Вам необходимо добиться того чтобы утилита dpkg-checkbuilddeps не выдавала сообщений о неудовлетворенных зависимостях. Можете попробовать собрать неудовлетворенную зависимость или понизить требования к номеру версии или покомбинировать эти два варианта.
Сборка пакета
Простая сборка
Итак, все что необходимо нам для сборки, установлено. Осталось, собственно, собрать пакет. Для этого нам понадобится утилитка fakeroot , установите ее, если она у Вас еще не установлена.
Переходим в каталог с распакованным src-пакетом и даем команду:
- $ dch -i
Отдельно надо рассмотреть вопрос о том, какую версию указывать в changelog.
- Это не должна быть версия, встречающаяся в официальном репозитории (чтобы не создавать путаницы)
Если вы делаете просто бэкпорт, то версия должна быть младше той версии, на основе которой собран пакет (чтобы не возникло проблем, когда этот пакет попадет в testing, затем в stable и вы попробуете сделать dist-upgrade). Добавьте строку ~backports1 к номеру версии в таком случае. Позже, если в репозитариях окажется пакет с таким же номером версии, то ваша система произведет его обновление. Цифра 1 в данном случае может означать номер Вашей сборки, а слово backports может быть заменено на любое другое, которое будет более информативным.
Исходя из этого, правильным будет добавить к версии -какаятострока1 , если вы что-то существенно дорабатывали, или ~какаятострока1 , если делали бэкпорт.
$ fakeroot ./debian/rules binary или $ dpkg-buildpackage -rfakeroot или #debuildВ результате будет в родительском каталоге собран двоичный пакет, ради которого затевалась вся катавасия.
Проблемы на этом шаге могли возникнуть только в двух случаях:
- Вы что-то не (так) сделали на предыдущих шагах (например, понизили зависимость, а реально этого делать было нельзя);
Вы наткнулись на ошибку в src-пакете. Такое тоже иногда случается. Бывает, что пакеты не собираются, например, из за "неверно" установленного umask . Вообще, сборка пакетов от umask зависеть не должна, но этот баг почему-то довольно часто встречается в Debian.
Вернитесь на несколько шагов назад и повторите попытку.
Если есть только архив с исходниками
Итак, у нас есть только fluxbox-0.9.15.tar.bz2. Обычно выполняюncz следующие действия: Предварительно подготавливаю рабочую директорию:
mkdir ~/src/fluxbox mkdir ~/src/fluxbox/0.9.15 cd ~/src/fluxbox/0.9.15 wget "http://<путь до файла>" (можно конечно и просто через браузер скачать но обычно так быстрее)Получаем файл fluxbox-0.9.15.tar.bz2. Немного забегая вперёд, обработаем файл программой gzip.
bunzip2 fluxbox-0.9.15.tar.bz2 gzip fluxbox-0.9.15.tarПолучим fluxbox-0.9.15.tar.gz, переименуем:
mv fluxbox-0.9.15.tar.gz fluxbox_0.9.15.orig.tar.gz(т.е. разделили имя и версию подчёркиванием и после версии добавили слово orig: fluxbox_0.9.15.orig.tar.gz) Теперь распаковываем его (но ни в коем случае не удаляем!):
tar zxvf ./fluxbox_0.9.15.orig.tar.gz cd fluxbox-0.9.15Для корректной сборки нужно, чтобы корневая директория содержала не только название, но и версию! Ниже будем считать директорию ~/src/fluxbox/0.9.15/fluxbox-0.9.15 корневой директорией исходников. Далее выполняем «черновую» сборку. Т.е. делаем, как обычно
./configure --prefix=/usr && make(но не устанавливаем!) Если конфигурируется со всеми нужными опциями и собирается в бинарный файл, значит осталось только дебианизировать.
Если есть только deb-пакет
Распаковываем пакет в папку /tmp/program/
$ dpkg -x program*.deb /tmp/programЧтобы распаковать информацию о пакете, нужно выполнить:
mkdir /tmp/program/DEBIAN $ dpkg -e program*.deb /tmp/program/DEBIANТеперь можно делать изменения. Чтобы снова собрать пакет, делаем следующее:
$ dpkg - b /tmp/program program-new*.debДебианизация
Cмысл всей этой процедуры - создать директорию debian в корне исходников, с нужными файлами конфигурации и скриптом(ами). Для этого, в корне исходных текстов (~/src/fluxbox/0.9.15/fluxbox-0.9.15), выполним:
dh_make Type of package: single binary, multiple binary, library, kernel module or cdbs? s Maintainer name: Frank Email-Address: [email protected] Date: Wen, 20 Mai 2011 12:40:33 +0200 Package Name: fluxbox Version: 0.9.15 License: GPLv3 Type of Package: Single HitЗдесь мы указываем сформировать пакет для одиночного бинарного файла. Если бы мы не переименовали архив, то получили бы следующее сообщение:
Could not find fluxbox_0.9.15.orig.tar.gz Either specify an alternate file to use with -f, or add --createorig to create one.В таком случае советую прервать dh_make (Ctrl+C) и переименовать архив, как описано выше. Но мы с вами молодцы и всё у нас прошло без ошибок - появился каталог debian в корне исходников, посмотрев его содержимое, Вы увидите кучу файлов (расширение.ex) с примерами на все случаи жизни. Будем считать, что программа у нас простая, обычно ни один из этих файлов не нужен. Первым делом нужно добавить описание программы в файле debian/control :
Description:Вместо
- dh_install
без этого мы получим пустой пакет. Обычно этих настроек достаточно для сборки пакета с одной программой, которая не содержит разделяемых библиотек, т.е. только бинарник в /usr/bin и данные в /usr/share. Теперь, соберём пакет:
dpkg-buildpackage -rfakerootв директории выше, т.е. в ~/src/fluxbox/0.9.15, мы получим файлы:
cd .. ls -1 fluxbox_0.9.15-1.diff.gz fluxbox_0.9.15-1_i386.changes fluxbox_0.9.15-1_i386.deb fluxbox_0.9.15.orig.tar.gzУстановка пакета
После того, как пакет собран, его осталось установить командой:
dpkg -i имя_пакета.debИли включить его в состав собственного репозитария. Это уже базовые вещи в системе Debian, поэтому их описание наведено в других статьях вики.
Сборка с созданием чистых образов систем
На самом деле, для того, чтобы собрать пакет правильно, его надо собирать в минимальной системе, где стоят только build-essential и зависимости этого пакета. Тогда, во-первых, не будет никаких накладок из-за того, что у вас в системе стоят некоторые пакеты вообще неизвестно откуда и непонятно каких версий (и в итоге в зависимостях у бинарного пакета могут оказаться пакеты версий, отсутствующих в том дистрибутиве, под который вы хотите собрать пакет), а во-вторых, вы избежите накладок (крайне редких, но все же), когда установленный лишний пакет как-то (читай негативно и не всегда очевидно) влияет на сборку.
В качестве решения подойдет chroot с чистым окружением… Испугались? Все уже украдено до нас.
Сборка пакета в системе pbuilder
Довольно неплохо упрощает данный процесс интерактивная программа pbuilder . Установите пакет pbuilder , затем откройте на редактирование /etc/pbuilderrc и пропишите адрес Вашего любимого репозитория.
Выполните команды:
# pbuilder update # pbuilder create --distribution """sarge"""система готова к употреблению.
Вместо имени sarge подставьте название Вашего дистрибутива.
теперь чтобы собрать пакет для выбранного дистрибутива дайте команду:
# pbuilder build package-version.dscБудут автоматически проделаны все описанные выше шаги, при этом все пакеты требуемые для сборки скачиваются и устанавливаются во временный каталог, поэтому система не "замусоривается" лишними пакетами. Правда, проблему с зависимостями для сборки всё равно придется решать, однако последовательно пройти по всем зависимостям с данным инструментом не представляет особого труда. Почитайте документацию на этот замечательный пакет и узнайте об остальных его возможностях.
Сборка пакета в системе cowbuilder
сowbuilder является из пакета cowdancer – это аналог pbuilder, только образ сборочной системы он хранит не в tar.gz а в развернутом виде, а при сборке копирует этот образ с использованием техники copy-on-write, что ускоряет сборку.
Пример конфига /etc/pbuilderrc:
BUILDPLACE=/var/cache/pbuilder/build/ USEPROC=yes USEDEVPTS=yes USEDEVFS=no BUILDRESULT=/var/cache/pbuilder/result/ #у меня кэширующий apt-cacher, пожтому я отключил кэширование пакетов внутри pbuilder #APTCACHE="/var/cache/pbuilder/aptcache/" APTCACHE="" REMOVEPACKAGES="" HOOKDIR="" export DEBIAN_FRONTEND="noninteractive" DEBEMAIL="Alexander GQ Gerasiov < [email protected] >" BUILDSOURCEROOTCMD="fakeroot" PBUILDERROOTCMD="sudo" DEBBUILDOPTS="" APTCONFDIR="" BUILDUSERID=1000 BUILDUSERNAME=gq export LOGNAME=gq BINDMOUNTS="" unset DEBOOTSTRAPOPTS export PATH="/usr/sbin:/usr/bin:/sbin:/bin:/usr/X11R6/bin" export SHELL=/bin/bash DEBOOTSTRAP="cdebootstrap" PKGNAME_LOGFILE_EXTENTION="_$(dpkg --print-architecture).build"Создать образ системы можно и без использования конфига:
# cowbuilder --create --distribution sid --architecture i386Теперь логинимся в чистую систему:
# cowbuilder --login --save # aptitude install devscriptsВиход из окружения стандартен, собраные пакеты искать в /var/cache/pbuilder.
exit или Сtrl+DСборка пакета в чистом окружении
Как теперь собрать пакет в нужном окружении. Вначале из нашего каталога <имя пакета>-<версия апстрим> с измененной версией и поправленными build-depends собираем сурцовый пакет новой версии:
dpkg-buildpackade -rfakeroot -SПереходим каталогом выше, где собрался файлик <имя пакета>_<версия>.dsc (где версия, это уже наша версия с “~backport”) и говорим
pbuild --dist sarge <имя пакета>_<версия>.dscЕсли произошла ошибка (например из-за проблем с зависимостями), то возвращаемся к шагу 1 и исправляем ошибки. Если все прошло нормально, то собранные пакеты окажутся в каталоге /var/cache/pbuilder/results. Вот собственно и все.
Для обновления образов (особенно актуально для testing) я использую команду
pbuild --dist etch --updateПример скрипта автоматизации: || ||
Пример скрипта автоматизации для нескольких релизов: || ||
Удаление зависимостей для сборки
Для этого можно использовать deborphan :
$ deborphan или $ deborphan -guess-dev или сразу удалить: # deborphan -guess-dev | xargs apt-get remove -purge -yили же скриптом(проверено PavloRudyj):
# aptitude markauto $(apt-cache showsrc PACKAGE_NAME | grep Build-Depends | perl -p -e "s/(?:[\[(].+?[\])]|Build-Depends:|,|\|)//g")Частенько возникает необходимость собрать пакет с какими либо файлами, из которых скомпилировать ничего нельзя. В моём случае это чаще всего самописные bash-скрипты, файл с public ключами ssh… Ещё интересная идея так же паковать архивы.
В рассмотренном ниже примере мы создадим один deb пакет с аж тремя вкусными штуками:
1) конфигурационные файлы nginx с нашего сервера
2) файл с public ключами для авторизации обладателей закрытой части этих ключей на сервере рутом
3) скрипт /usr/bin/ourscript.sh (неважно что он делает, по сути)
Принцип одинаковый, просто мне удобно показать сразу три примера. Пакет будет называться nginxsuperconfig
Предрекая вопросы «а зачем тебе fakeroot, если всё делаешь рутом?». Удобно . А главное — просто и быстро.
Начнем-с с создания нужных каталогов и копирования в эту структуру нужных нам файлов. Каталог DEBIAN должен быть написан именно большими буквами. Остальные каталоги — воссоздание структуры необходимых нам файлов с условным корнем в виде каталога /root/builder/nginxsuperconfig/. То есть всё, что лежит в этом каталоге (кроме DEBIAN) просто распакуется в корень. Как будто вы создадите tarболл с содержимым этого каталога и распакуете его в корень.
root@builder:~# mkdir -p /root/builder/nginxsuperconfig/DEBIAN
root@builder:~# mkdir -p /root/builder/nginxsuperconfig/etc
root@builder:~# mkdir -p /root/builder/nginxsuperconfig/usr/bin
root@builder:~# mkdir -p /root/builder/nginxsuperconfig/root/.ssh
root@builder:~# cp -r /etc/nginx /root/builder/nginxsuperconfig/etc
root@builder:~# cp /usr/bin/ourscript.sh /root/builder/nginxsuperconfig/usr/bin/
root@builder:~# cp /root/.ssh/authorized_keys /root/builder/nginxsuperconfig/root/.ssh/
Теперь нам понадобится написать файлы, описывающие свойства пакета. Обязательным является только файл DEBIAN/control. Для примера я ещё напишу несколько скриптов — один из них будет выполняться перед установкой пакета, второй — по окончанию и ещё один — при удалении пакета.
Напишем файл control:
root@builder:~# editor /root/builder/nginxsuperconfig/DEBIAN/control
Я перечислю обязательные поля. На самом деле туда можно много чего написать, но это уже лучше поискать в сети:
Package: nginxsuperconfig
Version: 1.0-1
Section: misc
Priority: extra
Maintainer: inkvizitor68sl
Architecture: all
Depends: nginx, openssh-server, bash
Description: Example package
Package with nginx configs, ssh keys, example script.
Немного прокомментирую.
Package — название пакета.
Version — версия. Через дефис пишем «номер сборки». Например, если вы слегка поправили файл в содержимом, но версия пакета не сменилась. В данном случае мы сами решаем какая у нас версия, потому можно не париться и всегда ставить версия-1
Section — для случаев рассмотренных в примере больше всего подходит misc
Priority — аналогично, подходит extra
Maintainer — ваше имя/ник и почта
Depends — в простейшем случае через запятые перечисляем имена пакетов, которые должны быть установлены, чтобы ваш пакет работал. В нашем случае — nginx (мы же для него конфиг льем), openssh-server (а зачем ключи, если ssh сервера нет?), bash, без которого не запустится наш скрипт.
Description — строка с кратким описанием пакета (не более 70 символов). Следующие строки — полное описание пакета. Перенос строки — точка.
Теперь создадим нужные скрипты.
Выполняемый перед инсталляцией:
root@builder:~# editor /root/builder/nginxsuperconfig/DEBIAN/preinst
#!/bin/bash
mv /etc/nginx /etc/nginx.bak
mv /root/.ssh/authorized_keys /root/.ssh/authorized_keys.old
Выполняемый после инсталляции:
root@builder:~# editor /root/builder/nginxsuperconfig/DEBIAN/postinst
#!/bin/bash
/etc/init.d/nginx restart
chmod +x /usr/bin/ourscript.sh
Выполняемый после удаления:
root@builder:~# editor /root/builder/nginxsuperconfig/DEBIAN/postrm
#!/bin/bash
rm -r /etc/nginx
mv /etc/nginx.bak /etc/nginx
rm /root/.ssh/authorized_keys
mv /root/.ssh/authorized_keys.old /root/.ssh/authorized_keys
Ещё можно создать выполняемый перед удалением скрипт:
root@builder:~# editor /root/builder/nginxsuperconfig/DEBIAN/prerm
В общем-то всё готово к сборке пакета:
root@builder:~# cd /root/builder/
root@builder:~# fakeroot dpkg-deb --build nginxsuperconfig
Мы получим файл nginxsuperconfig.deb. Неплохо его ещё переименовать, чтобы в названии содержалась версия:
root@builder:~# mv nginxsuperconfig.deb nginxsuperconfig_1.0-1.deb
Вот в общем-то и всё. Напоминаю, что это простейший пример. Я не ставил перед собой задачи написать очередной огромный непонятный мануал про сборку пакетов. Я постарался описать именно простейший способ собрать свой собственный deb пакет с данными. Ах да, не забудьте, что таким способ можно собрать метапакет для личного использования. То есть пакет, который сам ничего не содержит, зато по зависимостям тянет всё нужное.
Куда слать вопросы, думаю, знаете =)
