DEBIAN/copyright: / лицензия

DEBIAN/changelog: история изменений

O_O Tync Sun, 13 Dec 2009 00:11:46 +0300

DEBIAN/conffiles: список файлов конфигурации

DEBIAN/dirs: список папок для создания

DEBIAN/menu: создание пунктов меню

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

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

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

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

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

# ======[ 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: шаблоны для диалогов

Template - уникальный (в пределах одного пакета) идентификатор шаблона. Если в скрипте нужно вызвать определённый диалог - используется именно это имя.
Type - тип шаблона. Определены такие типы: string, password, boolean, select, multiselect, text, note, error.
Default-value - значение по умолчанию: пользователь может просто согласиться с ним.
Description - как и в контрольном файле, состоит из двух полей: короткое описание, и длинный текст. Первое - это заголовок «окна», второе - более развёрнутое описание того, что требуется от пользователя. Рекомендуется не использовать слов вроде «введите», а сразу суть: «Приветствие скрипта», «Точка монтирования»,…

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

# Подключение команд 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

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

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

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

Создаём собственный репозиторий пакетов

Описание будущего репозитория

В нашем деле создания простого репозитория все поля не играют принципиальной роли, и используются лишь для визуального определения «что есть что»:)

Создание репозитория

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

Финиш

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

Введение

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

Частенько возникает необходимость собрать пакет с какими либо файлами, из которых скомпилировать ничего нельзя. В моём случае это чаще всего самописные 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 пакет с данными. Ах да, не забудьте, что таким способ можно собрать метапакет для личного использования. То есть пакет, который сам ничего не содержит, зато по зависимостям тянет всё нужное.
Куда слать вопросы, думаю, знаете =)

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 Architecture: i386 Version: 1.0 Depends: libc6 (>= 2.1) Description: Short description here Long description here

• 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 и устанавливайте свои программы сколько душе угодно.

Зачастую некоторый пакет имеется в ветках unstable и experimental , однако его нет в ветках stable /testing . Программу поставить очень хочется, а обновлять полсистемы страшновато или нежелательно.

Для таких случаев есть замечательный ресурс backports.org , однако его использование во многом похоже на прямое использование веток unstable и иногда доставляет бОльшие проблемы из-за периодически возникающих конфликтов между backports и unstable.

В большинстве случаев установить пакет из 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/ вместе с исходными текстами.

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 .

Получение и распаковка пакета с исходными текстами

для нашего случая с fluxbox это будет выглядеть так:

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

В результате этого действия, как видно из приведенного выше лога, были скачаны нужные файлы с зеркала (которое мы прописали в /etc/apt/sources.list ) и произведена распаковка исходников и наложение патча в .diff.gz .

Данную операцию необязательно было проделывать с помощью apt-get , можно было пойти на страничку пакета , скачать файлы по ссылке Downloads (внизу страницы) и распаковать командой

Также можно использовать утилиту dget, которая скачает весь пакет и сразу распакует исходники:

Немного об устройстве каталога 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 настроен так, как было указано выше, то в большинстве случаев установка зависимостей может быть сделана одной командой:

Для рассматриваемого нами пакета 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 , если делали бэкпорт.

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

Проблемы на этом шаге могли возникнуть только в двух случаях:

• Вы что-то не (так) сделали на предыдущих шагах (например, понизили зависимость, а реально этого делать было нельзя);

Вы наткнулись на ошибку в src-пакете. Такое тоже иногда случается. Бывает, что пакеты не собираются, например, из за "неверно" установленного umask . Вообще, сборка пакетов от umask зависеть не должна, но этот баг почему-то довольно часто встречается в Debian.

Вернитесь на несколько шагов назад и повторите попытку.

Если есть только архив с исходниками

Итак, у нас есть только 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 в корне исходников, с нужными файлами конфигурации и скриптом(ами). Для этого, в корне исходных текстов (~/src/fluxbox/0.9.15/fluxbox-0.9.15), выполним: