Создание deb-пакетов. Первые шаги в PPA
Данная статья посвящена теме сборки deb-пакетов с использованием сервиса Launchpad PPA. Перед прочтением данной статьи, настоятельно рекомендую ознакомиться с записью в блоге тов. Ky6uk'а - http://ky6uk.org/launchpad-its-really-simple. Именно там Вы можете узнать как создать и настроить свой PPA на Launchpad.net.
раскрыть тему
Итак, приступим сразу к делу.
Для начала нам понадобится установить пакеты, требующиеся для подготовки пакета к сборке, и его передачи на сервер с PPA:
Установка необходимых пакетов
sudo apt-get install dh-make devscripts debhelper dput
Так же нам понадобится подопытный проект исходных кодов, воспользуемся для этого проектом qmmp - получим самую свежую ревизию из Subversion (для получения более подробной информации смотрим в http://code.google.com/p/qmmp/source/checkout):
Установка SVN и извлечение исходных кодов qmmp
#устанавливаем Subversion
sudo apt-get install subversion
#создаем папку для исходников и получаем свежую ревизию
mkdir -p ~/debpack/qmmp/qmmp-0.7-ppa+svn
cd ~/debpack/qmmp/qmmp-0.7-ppa+svn/
svn co http://qmmp.googlecode.com/svn/trunk/qmmp ./
Следует отметить, что структура папок при подготовки должна быть именно двухуровневой: qmmp/qmmp-0.7-ppa+svn, это сделано для того, чтобы все служебные файлы при подготовке пакета исходников скапливались не в корневой папке debpack, которая может служить корневой папкой для нескольких проектов. При такой структуре все служебные файлы будут валиться в папку debpack/qmmp. Естественно, вы вольны выбирать названия папок на свое усмотрение, с одним ограничением - папка с исходниками должна иметь вид <название-проекта>-<версия[дополнительная-информация]>. По поводу данных требований можно почитать на http://www.debian.org/doc/manuals/maint-guide/first.ru.html.
Очень важно знать и уметь собрать данный проект самостоятельно из исходных кодов. Как бы вам не хотелось обойтись без этого, но именно знание о правилах сборки проекта из сырцов - одно из важнейших условий для быстрой настройки пакета исходных кодов к пакетированию.
Еще одно очень важное требование - четко определить список пакетов, нужных для сборки проекта. Обычно разработчики указывают зависимости сборки в файле README. Читаем файл README.RUS. Там четко расписано, какие пакеты нужны для сборки:
Листинг части файла README.RUS
Требования:
- Qt >= 4.6
- tar, unzip, bzip2, gzip
- libmad
- libvorbis
- libogg
- libalsa >= 1.0.1
- taglib >= 1.6
- curl >= 7.16
- libmms >= 0.4 (Опционально)
- flac >= 1.1.3 (Опционально)
- libmpcdec >= 1.2.6 (Опционально)
- jackit >= 0.102.5 (Опционально)
- libsamplerate >= 0.1.2 (Опционально)
- libmodplug >= 0.8.4 (Опционально)
- libsndfile >= 1.0.17 (Опционально)
- wavpack >= 4.41 (Опционально)
- pulseaudio >= 0.9.15 (Опционально)
- ffmpeg >= 0.9.1 (Опционально)
- libcdio >= 0.80 (Опционально)
- libcdio-paranoia >= 10.2 (начиная с libcdio 0.90)
- libcddb >= 1.3.1 (Опционально)
- faad2 >= 2.6.1 (Опционально)
- game-music-emu >= 0.5.5 (Опционально)
- libWildMidi >= 0.2.3.4 (Опционально)
- libbs2b >= 3.0.0 (Опционально)
- libprojectM >= 1.2.0 (Опционально)
- libenca >= 1.9 (Опционально)
- mplayer (Опционально)
- cmake >= 2.6.0 (только для сборки)
Внимание! Для сборки Qmmp нужна утилита lrelease. Очень часто она находится в пакете libqt4-devel.
....
Если какой-либо модуль (например, Jack) не собирается или не нужен, то вы можете отключить его командой:
cmake ./ -DUSE_JACK:BOOL=FALSE
Вот эту информацию мы и будем использовать при подготовке пакета.
Этап 1. Подготовка к пакетировнию
Для подготовки к пакетированию, нам понадобится dh_make. Заходим в папку с исходными кодами и запускаем dh_make с нужными параметрами (список параметров - man dh_make):1
#Переходим в каталог с исходниками
cd ~/debpack/qmmp/qmmp-0.7-ppa+svn
#создаем папку debian с файлами для сборки пакета при помощи dh_make
dh_make -e you.email@example.com -c gpl --createorig
Рассмотрим параметры:
-e - указывает электронную почту меинтейнера. Одно важное замечание: этот адрес должен совпадать с адресом, указанным Вами при генерации подписи pgp для своего PPA.
-с - указывает лицензию, под которой распространяется данный проект
--createorig - говорит о необходимости автоматического создания «оригинального пакета исходников». Этот архив с исходниками будет использоваться как эталон, все последующие изменения в исходниках или настройках пакетирования будут накладываться на него в виде патчей.
В ответ на команду dh_make мы увидим запрос:
Type of package: single binary, indep binary, multiple binary, library, kernel module, kernel patch?
[s/i/m/l/k/n] s
Здесь выбираем s, т. к. нам нужно собрать просто бинарный пакет. Про остальные варианты я напишу как-нибудь потом, жаждущим познания советую просто обратиться в Google для поиска интересующих сведений. В ответ на выбор получаем вывод с информацией:
Maintainer name : your_name
Email-Address : your_email
Date : Tue, 25 Dec 2012 10:55:50 +0700
Package Name : qmmp
Version : 0.7-ppa+svn
License : gpl3
Type of Package : Single
Hit to confirm:
Если Вас не устроила какая-либо указанная информация, смело жмите Ctrl+C для отказа, а если Вы со всем согласны, то жмите Enter.
Имя меинтейнера берется из переменных окружения, для более комфортной работы при пакетировании рекомендую установить следующие переменные окружения (можно настроить используемую Вами оболочку для автоматического экспорта этих переменных):
Экпорт переменных окружения для dh_make
export DEBFULLNAME="your_name"
export EMAIL=you.email@example.com
export DEBEMAIL=you.email@example.com
Значения имени и e-mail должны буть такие же как и в pgp подписи PPA. После нажатия на клавишу Enter видим сообщение о завершении генерации нужных файлов:
Done. Please edit the files in the debian/ subdirectory now. qmmp
uses a configure script, so you probably don't have to edit the Makefiles.
Теперь в папке с сырцами появилась папка debian, в которой очень много интересных и полезных файлов. Именно редактирование этих файлов и будет указывать PPA как именно нужно собирать пакет, куда его устанавливать и даже опишет пункт меню программы.
Этап 2. Конфигурация пакета исходных кодов
Все операции на данном этапе будут совершаться над файлами в папке debian, о назначении каждого из файлов Вы можете узнать по адресу http://www.debian.org/doc/manuals/maint-guide/index.ru.html.
Зайдем в каталог debian и удалим все *.ex и *.EX файлы, кроме menu.ex и postinst.ex, в данном случае они нам не нужны. Теперь заглянем в файл changelog:
Листринг файла debian/changelog
qmmp (0.7-ppa+svn-1) unstable; urgency=low
* Initial release (Closes: #nnnn)
-- your_name ; Tue, 25 Dec 2012 10:55:50 0700
В первую очередь нас интересует первая строка - нам надо поменять unstable на кодовое имя дистрибутива Ubuntu, под которую будет собираться пакет (для Debian, соответственно). Возможно указание нескольких целевых дистрибутивов, разделенных пробелами. Пусть целевым дистрибутивом у нас будет Ubuntu 12.10 quantal.Переходим к следующей строке, там где под '*' указываются изменения, произошедшие в программе, например, исправленные ошибки или ограничения к данной версии программы. Мы можем указать там что-то своё.И, наконец, последняя строка - указание автора и времени изменений. По началу меня напрягало редактировать время модификации, ведь оно должно быть в формате RFC-2822. На самом деле здесь все просто - после каждого изменения я просто делал команду date -R в каталоге debian:
Добавление даты изменения в формате RFC-2822
date -R >> changelog
После чего старая дата модификации благополучно мной стиралась, а на её место становилась новая.
Итак, в итоге мы имеем файл changelog такого вида:
Листинг отредактированного файла debian/changelog
qmmp (0.7-ppa+svn-1) quantal; urgency=low
* Initial release
* This is my first build the project
-- your_name ; Tue, 25 Dec 2012 10:55:50 0700
Редактируем файл copyright:
Листринг части файла debian/copyright
Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
Upstream-Name: qmmp
Source:
Files: *
Copyright:
License: GPL-3.0
Files: debian/*
Copyright:
License: GPL-3.0+
...
Подставляем URL с исходниками данного проекта в строку Source (можно указать ссылку на http://qmmp.googlecode.com/svn/trunk), исправляем строку Copyrights - подставляем год и список авторов. Тут все просто. А теперь задача посложнее: редактирование файла control. К редактированию этого файла следует отнестись очень ответственно, содержимое этого файла напрямую влияет на сборку исходников в PPA. Вот содержимое файла control, сгенерированного dh_make:
Листинг файла debian/control
Source: qmmp
Section: unknown
Priority: extra
Maintainer: ;
Build-Depends: debhelper (>= 8.0.0), cmake
Standards-Version: 3.9.3
Homepage:
#Vcs-Git: git://git.debian.org/collab-maint/qmmp.git
#Vcs-Browser: http://git.debian.org/?p=collab-maint/qmmp.git;a=summary
Package: qmmp
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Description:
Файл имеет 2 секции: Source - все, что относится к сырцам и Package - все что относится к будущему собранному пакету. Нам требуется грамотно отредактировать первую секцию и немного подправить вторую. Начнем с исправления строки Section, здесь указывается тип и секция к которой относится данная программа. В Ubuntu существует 4 типа:
Main - официально поддерживаемое ПО;
Restricted - ПО, не доступное по свободной лицензии;
Universe - ПО, поддерживаемое сообществом;
Multiverse - несвободное ПО.
Список подсекций можно посмотреть тут - http://www.debian.org/doc/debian-policy/ch-archive.html#s-subsections.
Исходя из всего вышеперечисленного получаем, что Section у нас будет universe/sound. Идем дальше - Priority. Здесь следует выбирать значение исходя из необходимости приложения. Обычно это extra, почитать про приоритеты можно по той же ссылке, что и про секции.
А вот и самое интересное - Build-Depends - в этом поле указываются зависимости сборки проекта сырцов. Именно здесь мы и используем требования файла README, а точнее нам потребуются dev (пакеты для разработчиков, где обычно находятся заголовочные файлы) пакеты указанных зависимостей. Тут я иду в synaptic и ищу необходимые пакеты-зависимости, хотя вы можете использовать собственные методы определения имен пакетов. В поле Homepage указываем домашнюю страницу проекта.
Во 2-ой секции самым важным является определение целевой архитектуры пакета, зависимости и, думаю, не менее важным - описание назначения пакета. Про поле Architecture можно прочитать тут - http://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-arch-spec. Как правило, если вы собираете бинарный пакет, то вы желаете собрать его сразу для i386 и amd64 архитектуры, а это можно обеспечить указанием в данном поле опцией any. Поле Depends обычно автоматически заполняется системой сборки пакета на основании данных линковщика, однако иногда нужно указать явно пакет, от которого зависит работоспособность приложения, но оно явно не линкуется с этой зависимостью. У меня в практике было так, что для проекта REXLoader обязательно требовалось наличия плагина-драйвера Qt для работы с СУБД SQLite. Мне пришлось самостоятельно указать нужный пакет в данном поле. Зависимости перечисляются через запятую, переносы строк не допускаются - все должно быть в одной строке.
Поле Description позволяет описать пакет: его назначение и свойства. Тут нужно быть внимательным в следующем: сразу после 'Description: ' пишется краткое описание пакета длинной до 60 символов. Более подробное описание пакета и его свойств можно начать со следующей строки, соблюдая правила отступа с начала строки, т. е. Все последующие строки описания должны начинаться с одиночного пробела, не табуляции, а именно с пробела! При этом все предложения, написанные в 1 строке окажуться в пределах одного абзаца. Следующий абзац начинаем с переноса на новую строку и отступа в один пробел.
Вот что у меня получилось для нашего проекта сырцов:
Source: qmmp
Section: universe/sound
Priority: extra
Maintainer: your_name ;
Build-Depends: debhelper (>= 8.0.0), cmake (>= 2.6.0), g++ (>= 4.6.0), libqt4-dev, libqt4-opengl-dev, libmad0-dev, libvorbis-dev, libogg-dev, libasound2-dev, libtagc0-dev, curl (>= 7.16), libmms-dev, libflac-dev, libmpcdec-dev, libjack-jackd2-dev, libsamplerate0-dev, libmodplug-dev, libsndfile1-dev, libwavpack-dev, libpulse-dev, libffms2-dev, libcdio-dev, libcdio-paranoia-dev, libcddb2-dev, libfaad-dev, libgme-dev, libwildmidi-dev, libbs2b-dev, libprojectm-dev, libenca-dev, mplayer, qt4-linguist-tools
Standards-Version: 3.9.3
Homepage: http://qmmp.ylsoftware.com/
#Vcs-Git: git://git.debian.org/collab-maint/qmmp.git
#Vcs-Browser: http://git.debian.org/?p=collab-maint/qmmp.git;a=summary
Package: qmmp
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, mplayer
Description: qmmp - A Qt-based multimedia player
Yes!
It's my first maintain build deb-package.
Ого, как много мне пришлось искать и вписывать в этот файл, и это далеко еще не все! Поехали дальше.
Теперь самое-самое главное - правильно указать сборщику, как собрать проект сырцов в бинарный проект, а его, в свою очередь, в deb-пакет. Для начала давайте немного отвлечемся и ответим на вопрос «Что такое установка приложения в GNU/Linux?». Любой знающий структуру каталогов GNU/Linux человек ответит, что установка приложения - есть копирование файлов собранного проекта в с соответствующие директории файловой системы GNU/Linux. Отсюда и будем «плясать».
Возвращаемся к файлу rules, первоначальное его содержимое должно напоминать нечто следующее:
#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# This file was originally written by Joey Hess and Craig Small.
# As a special exception, when this file is copied by dh-make into a
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of dh-make.
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
%:
dh $@
Этого нам будет мало, ибо сборщик не выполнит ни сборку проекта, ни его упаковку в deb-пакет - он просто не знает как это сделать. Давайте научим его это делать. Не буду вдаваться в подробности, просто скажу, что Вы можете спокойно использовать нижеприведенный шаблон.
Листинг файла debian/rules
#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# This file was originally written by Joey Hess and Craig Small.
# As a special exception, when this file is copied by dh-make into a
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of dh-make.
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
build:
dh_testdir
# Add here commands to build the package
touch $@
clean:
dh_testdir
dh_testroot
rm -f build-stamp
# Add here commands to clean up after the build process.
rm -rf builddir
dh_clean
install: build
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs
# Add here commands to install the package into debian/your_appname
# Build architecture-independent files here.
binary-indep: build install
# We have nothing to do by default.
# Build architecture-dependent files here.
binary-arch: build install
dh_testdir
dh_testroot
dh_installdocs
dh_installexamples
dh_installman
dh_link
dh_compress
dh_fixperms
dh_installdeb
dh_shlibdeps
dh_gencontrol
dh_md5sums
dh_builddeb
binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install configure
Пока что этот файл лишен смысловой нагрузки - кроме действий по умолчанию он просто ничего не делает. Внимательно посмотрев на структуру файла мы видим, что он разделен на несколько секций (целей): build, clean, install и т. д.. Знающие люди воскликнут - «Это же Makefile!» и будут совершенно правы. Это именно Makefile для автоматического сборщика пакетов, а наша задача столь-же проста, сколь и ответственна - правильно описать все действия по сборке и установке пакета. Итак, приступаем!
Сперва программу нужно собрать из исходников, а как мы это сделаем для qmmp? Конечно же очень просто (как и со всеми проектами на cmake):
создадим папку, например, builddir
зайдем в эту папку
дадим в терминале команду cmake../
после успешной проверки зависимостей и конфигурации проекта делаем make
после успешной сборки - make install
Вот точно так же мы это опишем и rules, но только не на русском языке, а на понятном сборщику скриптовом языке:
#!/usr/bin/make -f
# -*- makefile -*-
# Sample debian/rules that uses debhelper.
# This file was originally written by Joey Hess and Craig Small.
# As a special exception, when this file is copied by dh-make into a
# dh-make output file, you may use that output file without restriction.
# This special exception was added by Craig Small in version 0.37 of dh-make.
# Uncomment this to turn on verbose mode.
#export DH_VERBOSE=1
build:
dh_testdir
# Add here commands to build the package
# Step 1. Создаем папку builddir
mkdir -p builddir
# Step 2 - 3. Переходим в созданную папку и делаем cmake ../
cd builddir && cmake ./ -DCMAKE_INSTALL_PREFIX=$(CURDIR)/debian/qmmp
# Step 4. Переходим в builddir и делаем make
cd builddir && make
touch $@
clean:
dh_testdir
dh_testroot
rm -f build-stamp
# Add here commands to clean up after the build process.
rm -rf builddir
dh_clean
install: build
dh_testdir
dh_testroot
dh_clean -k
dh_installdirs
# Add here commands to install the package into debian/your_appname
# Step 5. Переходим в builddir и делаем make install
cd builddir && make install
# Build architecture-independent files here.
binary-indep: build install
# We have nothing to do by default.
# Build architecture-dependent files here.
binary-arch: build install
dh_testdir
dh_testroot
dh_installdocs
dh_installexamples
dh_installman
dh_link
dh_compress
dh_fixperms
dh_installdeb
dh_shlibdeps
dh_gencontrol
dh_md5sums
dh_builddeb
binary: binary-indep binary-arch
.PHONY: build clean binary-indep binary-arch binary install configure
Здесь стоит отметить одну особенность: мы каждый раз вынужденны заходить в папку builddir. Так получается потому, что после выполнения любой команды/функции (цели) сборщик всегда возвращается в корень сборки. Кстати путь корневой папки сборки храниться в переменной CURDIR, поэтому при перемещении по каталогам удобно пользоваться выражением $(CURDIR)/path/to/dir.
Остались 2 последних файла, которые нужно настроить, причем оба они не обязательные и могут в вашем конкретном случае просто не использоваться.
Листинг файла menu.ex:
?package(qmmp):needs="X11|text|vc|wm" section="Applications/see-menu-manual"\
title="qmmp" command="/usr/bin/qmmp"
Это файл, который указывает Debian Menu System (читаем тут - http://www.debian.org/doc/packaging-manuals/menu-policy/) в какой раздел поместить ярлык на запуск программы, тут все предельно ясно. Сейчас используются совершенно другие методы для построения списка приложений, но файл рекомендую оставить для совместимости. Подправим содержимое файла:
?package(qmmp):needs="X11|text|vc|wm" section="Applications/Sound"\
title="qmmp" command="/usr/bin/qmmp"
Файл postinst.ex в данном случае намного важнее menu.ex. Дело в том, что проект qmmp использует собственные библиотеки, например libqmmp.so. Так вот те, кто сталкивался в работе с библиотеками знают одну особенность GNU/Linux: добавил новую библиотеку - обнови кэш ldconfig. Вручную это делается просто:
sudo ldconfig
Так вот, что-бы пользователь после установки нашего пакета не увидел ошибку при запуске qmmp о том, что приложение не нашло разделяемую библиотеку, и не перезагружал компьютер, мы должны предусмотреть автоматическое обновление кэша ldconfig сразу после копирования бинарных файлов проекта, т. е. сразу после установки. Файл postinst.ex представляет собой простой bash-скрипт, который выполняется с параметрами сразу после установки (копирования) файлов приложения. Давайте посмотрим на содержимое этого файла:
Листинг файла debian/postinst.ex
#!/bin/sh
# postinst script for qmmp
#
# see: dh_installdeb(1)
set -e
# summary of how this script can be called:
# *
`configure'
# * `abort-upgrade'
# * `abort-remove' `in-favour'
#
# *
`abort-remove'
# * `abort-deconfigure' `in-favour'
# `removing'
#
# for details, see http://www.debian.org/doc/debian-policy/ or
# the debian-policy package
case "$1" in
configure)
;;
abort-upgrade|abort-remove|abort-deconfigure)
;;
*)
echo "postinst called with unknown argument \`$1'" >&2
exit 1
;;
esac
# dh_installdeb will replace this with shell code automatically
# generated by other debhelper scripts.
#DEBHELPER#
exit 0
Как видно из содержимого скрипта, он обрабатывает входные параметры: configure, abort-upgrade, abort-remove, abort-deconfigure. Наша задача при вызове скрипта с параметром configure обновить кэш ldconfig, для этого дополним код скрипта:
Листинг файла debian/postinst.ex
#!/bin/sh
# postinst script for qmmp
#
# see: dh_installdeb(1)
set -e
# summary of how this script can be called:
# *
`configure'
# * `abort-upgrade'
# * `abort-remove' `in-favour'
#
# *
`abort-remove'
# * `abort-deconfigure' `in-favour'
# `removing'
#
# for details, see http://www.debian.org/doc/debian-policy/ or
# the debian-policy package
case "$1" in
configure)
echo "ldocnfig..." >&2
ldconfig
;;
abort-upgrade|abort-remove|abort-deconfigure)
;;
*)
echo "postinst called with unknown argument \`$1'" >&2
exit 1
;;
esac
# dh_installdeb will replace this with shell code automatically
# generated by other debhelper scripts.
#DEBHELPER#
exit 0
На этом подготовка исходных кодов к пакетированию завершена.
Этап 3. Отправка исходных кодов в Launchpad PPA
Итак, следующая наша задача - отправить подготовленный пакет исходных кодов в PPA. Тут следует отметить, что оригинальный пакет qmmp_0.7-ppa+svn.orig.tar.gz (который является эталоном кода) отправляется всего 1 раз при инициализации пакета в PPA. Все последующие изменения передаются в PPA в виде набора патчей.
Для формирования файлов, необходимых для автоматического сборщика, находясь в папке с исходными кодами (в той же папке, где и папка debian, созданная dh_make) даем команду:
debuild -S -sa
В итоге в каталоге на уровне выше рядом с файлом оригинальных кодов появятся ещё несколько файлов с расширениями *.changes, *.dsc и архив с текущими изменениями исходных кодов. Для отправки файлов на сервер в PPA пользуются приложением dput, но перед использованием это приложение нужно сконфигурировать. Создаем в домашнем каталоге своей учетной записи файл.dput.cf (имя файла начинается именно с точки) следующего содержания:
[ppa.myppa]
fqdn = ppa.launchpad.net
method = sftp
incoming = ~myppaname/myppa/ubuntu
login = myppaname
где [ppa.myppa] - идентификатор-имя, которое может быть любым, myppanem - имя пользователя учетной записи PPA, myppa - имя PPA.
Например ваш PPA имеет имя IvanPPA, учетная запись - IVAN, то файл будет такой:
[ppa.ivanppa]
fqdn = ppa.launchpad.net
method = sftp
incoming = ~ivan/ivanppa/ubuntu
login = ivan
Мой опыт в использовании dput указывает на то, что надежнее всего использовать sftp метод доставки файлов на сервер PPA. Предварительно вам потребуется зарегистрировать свой shh сертификат в своем PPA, как это сделать, написано тут - https://help.launchpad.net/YourAccount/CreatingAnSSHKeyPair. Вся информация для правильного формирования данного файла может быть получена в личном кабинете на сервере Launchpad.net.
А теперь, когда dput настроен, мы можем спокойно отправлять все файлы в PPA, для этого выходим в каталог ~/debpack/qmmp (там где лежат файлы.changes, *.dsc) и выполняем даем:
Отправка файлов на сервер PPA
dput ppa.ivanppa qmmp_0.7-ppa+svn-1_source.changes
При отправке файлов dput потребует ввести пароль от закрытого ключа ssh, сертификат которого должен быть зарегистрирован в вашем ppa. После успешной доставки всех файлов на сервер PPA вам должно придти уведомление на ваш e-mail (который зарегистрирован на сервер Launchpad.net) с сообщением о принятии пакета на исполнение (accept) или его отклонением (reject) с указанием причин. В сообщении с отказом обычно есть ссылка на список наиболее распространенных ошибок при формировании пакета исходных кодов, так что вы сможете без проблем определить, в чем ошиблись.
Этап 4. Обновление пакета исходных кодов в Launchpad PPA
Как уже отмечалось выше, обновление бинарных пакетов в PPA осуществляется наложением патчей на эталонный исходный код с последующей пересборкой пакета с увеличением номера версии пакета. Именно этим мы с вами сейчас и займемся.
Для начала нам нужно получить изменения из svn для нашего проекта qmmp - переходим в папку с исходными кодами ~/debpack/qmmp/qmmp-0.7-ppa+svn и получаем обновления:
Обновление дерева исходных кодов
svn update
Теперь нужно сделать так, чтобы эти изменения были отражены в файлах папки debian, но перед этим обязательно нужно отразить внесенные изменения в файле changelog в папке debian - как минимум нам нужно сменить номер версии сборки в первой строке этого файла с 1 на 2 (на и так далее по порядку, в зависимости от номер изменения):
Изменения в файле debian/changelog
qmmp (0.7-ppa+svn-2) quantal; urgency=low
* Update to SVN r3200
-- your_name ; Tue, 25 Dec 2012 10:55:50 0700
Там же можно описать все изменения данной версии (обычно это выгладит как текст разбитый на строки). Как обновлять дату и время внесения изменений говорилось выше (date -R >> changelog).
Принимаем все изменения в исходных кодах с помощью команды:
dpkg-source --commit
которая попросит нас ввести название текущего патча и описать все изменения, вносимые им. Я тут обычно просто ввожу порядковый номер патча (1, 2 ит.д.), а часть изменений, вносимых патчем автоматически будет взято из файла changelog. Дополнительно в описании патча можно будет указать авторов изменений и даже сайт-источник, откуда взят патч. Пример текста файла-описания патча
Листинг части файла-патча
Description:
TODO: Put a short summary on the line above and replace this paragraph
with a longer explanation of this change. Complete the meta-information
with other relevant fields (see below for details). To make it easier, the
information below has been extracted from the changelog. Adjust it or drop
it.
.
qmmp (0.7-ppa+svn-1) quantal; urgency=low
.
* Initial release
Author: your_name
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: ,
Bug:
Bug-Debian: http://bugs.debian.org/
Bug-Ubuntu: https://launchpad.net/bugs/
Forwarded:
Reviewed-By:
Last-Update:
--- /dev/null
+++ qmmp-0.7-ppa+svn/src/qmmpui/translations/libqmmpui_hu.qm
@@ -0,0 +1 @@
+<ždÊïÍ! ¿`¡œÝ
\ No newline at end of file
--- /dev/null
...
Редактирование файла описания патча будет производиться в консольном текстовом редакторе по-умолчанию (у меня это mcedit, у многих - nano). По окончании редактирования мы должны сохранить внесенные нами изменения определенным сочетанием клавиш (для mcedit - F10, nano - Ctrl+X). На вопрос сохранения внесенных изменений обязательно отвечаем согласием.
Теперь подошло время для создания.changes и *.dsc файлов для обновленной версии исходных кодов (команда должна выполняться в каталоге ~/debpack/qmmp/qmmp-0.7-ppa+svn):
debuild -S -sd
В итоге в каталоге ~/debpack/qmmp появятся новые файлы, в том числе и qmmp_0.7-ppa+svn-2_source.changes. Кстати, параметры '-sd' указывают debuild на то, что на сервер PPA нужно отправить только патч с изменениями, а не весь эталонный архив исходных кодов вместе с архивом измененных файлов.
Ну и последний шаг - отправка изменений на сервер PPA:
dput ppa.ivanppa qmmp_0.7-ppa+svn-2_source.changes
Обратите внимание на то, что теперь мы указываем dput уже файл qmmp_0.7-ppa+svn-2_source.changes, а не qmmp_0.7-ppa+svn-1_source.changes. Осталось только подождать уведомления в от сервера PPA с пометкой о принятии в работу ваших изменений. В случае отказа - смотрим на описание ошибки и пытаемся её устранить (после исправления ошибки вам понадобиться повторить команду debuild и dput, как описано выше).
http://spolab.ru/laboratory/articles/82-sozdanie-deb-paketov-pervye-shagi-v-ppa
http://www.debian.org/doc/manuals/maint-guide/first.ru.html
https://www.pgpru.com/chernowiki/rukovodstva/bezopasnostj/upravleniekljuchami/podkljuchiopenpgp
#######################################################################################################
Более простой способ:
В рассмотренном ниже примере мы создадим один 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
####################################################################
Собираем пакет! :)
Ура! Все нужные файлы созданы, лежат по нужным папочкам. Теперь пора собирать пакет :)
Первое, что нужно сделать - это рекурсивно выставить всем файлам в корне пакета пользователя и группу root:root (или другие, если потребуется). Это нужно затем, что файлы пакета упаковываются в tar.gz архив который сохраняет и права доступа к файлам, и владельца. Потому нужно выполнить:
$ sudo chown -R root:root
Однако делать это не обязательно. Есть отличная команда fakeroot которая при создании архива подменит владельца файлос root-ом.
В нашем примере, скрипт должен иметь бит выполнимости.
Потом выходим на папку назад, чтоб было видно корневую папку пакета, и пакет создаётся лёгким пинком сам:
$ fakeroot dpkg-deb --build supersh
Созданный пакет необходимо переименовать, чтобы он соответствовал порядку именования *.deb пакетов: <имя пакета>_<версия>_<архитектура>.deb
$ mv supersh.deb supersh_1.0-1_all.deb
Всё, пакет готов!
Автоматическая проверка пакета
Существует утилита lintian, позволяющая проверить пакет и выявить типичные ошибки в его структуре. Делается это так:
$ lintian supersh_1.0-1_all.deb
Установка пакета
$ sudo dpkg -i supersh_1.0-1_all.deb
Описание процесса сборки пакета deb
Как собрать бинарный deb пакет: подробное HowTo
Простейший способ собрать свой deb-пакет с данными (например, с конфигами, скриптами, ключами авторизации).
Памятка по управлению пакетами в Debian и Ubuntu