How-to`s — PPA своими руками с нуля. Часть 2. Новые версии имеющихся пакетов. Публикация на Launchpad

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

Часть 2.

1. Изменение пакета

Вернёмся к нашему hello-debhelper, который мы изучали в прошлой статье (надеюсь, вы не поудаляли все плоды трудов). Интересующие нас файлы уже лежат в поддиректории debian. Иногда её создают авторы ПО, но обычно этим занимаются те, кто пакет поддерживают, поэтому эта директория появляется при выполнении apt-get source после наложения debian-специфичного патча (*.diff.gz, вспоминайте предыдущую статью).

1 2 3 4 5 6 7 8

$ cd ubuntu/hello-debhelper-2.4/debian $ ls -l итого 28 -rw-r--r-- 1 divius divius 9432 2010-04-22 19:25 changelog -rw-r--r-- 1 divius divius 2 2010-04-22 19:25 compat -rw-r--r-- 1 divius divius 846 2010-04-22 19:25 control -rw-r--r-- 1 divius divius 2246 2010-04-22 19:25 copyright -rwxr-xr-x 1 divius divius 882 2010-04-22 19:25 rules

Прелесть пакета hello-debhelper в том, что он содержит только необходимый минимум. Итак, что мы имеем:
changelog - список изменений, вносимых в пакет теми, кто его поддерживать (не путать со списокм изменений в самом ПО!!!)
compat - уровень совместимости Debhelper (не требуется при сборке пакета без Debhelper, что, впрочем, бывает довольно редко). Это число. Правило простое: ставится максимальное число, поддерживаемое вашей версией Debhelper, в данный момент это 7.
control - файл, описывающий пакет. Синтаксис этого файла мы уже рассматривали, ниже мы рассмотрим этот файл ещё подробнее.
copyright - файл с информацией о правах. Пишется в свободной форме.
rules - файл формата Makefile, описывающий процесс сборки. В наличии этого файла и состоит гибкость системы пакетов Debian: туда можно вписать абсолютно что угодно. Но утилита Debhelper избавляет нас от необходимости вручную создавать этот файл (см. ниже).

1.1. Файл control

$ cat control
Source: hello-debhelper
Section: devel
Priority: extra
Maintainer: Santiago Vila <[email protected]>
Standards-Version: 3.8.3
Build-Depends: debhelper (>= 7)

Package: hello-debhelper
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}
Conflicts: hello
Provides: hello
Replaces: hello
Description: The classic greeting, and a good example
The GNU hello program produces a familiar, friendly greeting. It
allows non-programmers to use a classic computer science tool which
would otherwise be unavailable to them.
.
Seriously, though: this is an example of how to do a Debian package.
It is the Debian version of the GNU Project's `hello world' program
(which is itself an example for the GNU Project).
.
This is the same as the hello package, except it uses debhelper to
make the deb. Please see debhelper as to what it is.

Как мы видим, control содержит информацию о двух пакетах: пакете с исходным кодом (он всегда один) и бинарном пакете (таковых может быть сколько угодно). Более сложный пример - gThumb:



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

Отдельно стоит рассмотреть секцию Depends. В первую очередь мы видим 2 шаблона: ${misc:Depends} и ${shlibs:Depends}. Оба эти шаблона заменяются Debhelper на основе анализа пакета. Например, если в пакете присутствуют схемы gconf, он будет добавлен в качестве зависимости в ${misc:Depends}. Шаблон ${shlibs:Depends} заменяется на список разделяемых библиотек, полученный из двоичных файлов в пакете. Как вы видите, в нашем случае этот шаблон используется только в бинарных пакетах, содержащих исполняемый файлы: hello-debhelper и gthumb. Таким образом, самостоятельно в секцию Depends надо добавлять только то, что не подходит под эти 2 шаблона. Это ещё один пример того, как Debhelper облегчает жизнь создателем пакетов. Увы, но к секции Build-Depend всё это не относится. Ещё раз повторю, что в секцию Build-Depend надо добавлять ТОЛЬКО то, что используется на стадии сборки, а в секцию Depends - ТОЛЬКО то, что используется на стадии использования пакета конечным пользователем.

Также вы можете заметить, что в секции Architecture стоит либо any, либо all. Разница такова: all значит "подходит для любой архитектуры без пересборки", any значит "можно собирать под любую архитектуру". В пакете для конечного пользователя any будет заменено на соответствующую архитектуру.

Типичными являются строки типа:

Эта запись обозначает, что пакет hello-debhelper тождественен пакету hello, причём одновременно их ставить нельзя. Этот приём часто употребляется при переименовании пакета, например:


И последнее важное замечание: обратите внимание, что в файле control отсутствует версия пакета, ровно как и информация о том, кто в последний раз этот пакет изменят. Эта информация берётся автоматически из файла changelog.

1.2. Файл changelog

$ cat gthumb/debian/changelog
gthumb (3:2.11.3-0divius1~lucid0) lucid; urgency=low

* New upstream release:
- ftp://ftp.gnome.org/pub/GNOME/sources/gthumb/2.11/gthumb-2.11.3.news
- 05-fix_locales.patch disabled due to translations update
- 06-add_keybinding_DoNotSave.patch disabled to translations update
- 18-build_with_gtk2.19.patch disabled, no longer required

-- Dmitry Tantsur <[email protected]> Wed, 21 Apr 2010 22:06:12 +0400

gthumb (3:2.11.2.1-2) unstable; urgency=low

* debian/patches/:
- 18-build_with_gtk2.19.patch added (Closes: #573424)
* debian/rules:
- disable clutter at configure time (Closes: #573700, #573723)
* debian/control:
- remove Build-Dependencies on clutter things

-- David Paleino <[email protected]> Mon, 15 Mar 2010 07:43:28 +0100
(дальнейшая часть вывода пропущена)

Файл changelog состоит из многих записей, разделённых пустой строкой. Структура такова:

имя-пакета (версия-включая-версию-Debian) дистрибутив; urgency=важность

* Значительное изменение
- Пояснение или часть значительного изменения

-- Имя того, кто сделал изменение <почта того, кто сделал изменение>(2 пробела)дата и время

Теперь по пунктам:
Версия. Шаблон таков: версияПО-версияпакетаDebian. Версия ПО определяется разработчиками ПО, а вот версия пакета Debian определяется тем, кто пакет создаёт. Обычно имеет такой вид: A, AubuntuB, AubuntuB~ppaC, где A - версия пакета в Debian, B - версия изменений Ubuntu пакета Debian, C - версия ваших изменений пакета Debian, изменённого в Ubuntu. Не запутались?;) Ещё раз: Debian даёт пакету версию A (A >= 1). Когда разработчики Ubuntu изменяют этот пакет, они прибавляют к его версии "ubuntuB" (B >= 1). Если такого пакета в Debian не было, версия будет 0ubuntuB (опять же, B >= 1). А когда вы делаете изменения, вы прибавляете ещё постфикс, рекомендуется делать его через тильду, вот так: ~ppaC (C >= 1). Кроме того, посольку в вашем ppa будут пакеты для разных дистрибутивов, то надо ещё прибавить постфикс дистрибутива. Итого: AubuntuB~ppaC~lucid0. В моём пакете слово "ppa" заменено на мой ник для понимания, кто сделал пакет.
Важность - обычно "low".
Имя и почта должны совпадать с именем и почтой, значащайся в вашей подписи (см. ниже).
Дата и время - вывод date -R.

1.3. Файл rules

Файл rules на самом деле представляет собой Makefile, где цели binary и source отвечают за создание бинарного пакета и пакета с исходным кодом. Файл rules часто создаётся автоматически и обычно представляет собой набор вызовов команд Debhelper (dh_*). Если вы исправляете ошибки в имеющемся пакете, менять этот файл вам скорее всего не надо, и в этой статье я его разбирать не буду.

2. Создание подписи

Все наши усилия по созданию пакета пока упираются в отсутствие нашей подписи. Исправим этот недаразумение.

1	$ gpg --gen-key

Далее вам будут заданы несколько вопросов, значения по умолчанию вполне подойдут. Поле User ID должно в точности соответствовать тому, что вы пишите в changelog, то есть "Имя Фамилия ". Введите по очереди имя и почту, коментарий оставьте пустым.

После того, как вы создадите ключ (это займёт некоторое время), его можно просмотреть командой:

1 2 3 4 5 6

$ gpg --list-keys /home/divius/.gnupg/pubring.gpg ------------------------------- pub 2048R/12345678 2010-04-21 uid Dmitry Tantsur <[email protected]> sub 2048R/87654321 2010-04-21

Цифры 12345678 идентифицируют ваш ключ, они нам ещё пригодятся. Сделайте резервную копию ваших ключей (гугл в помощь), сертификат отзыва (подпись - не воробей, опубликуете - отозвать нельзя, если нет такого сертификата), опубликуйте информацию о ключе на сервере ubuntu и подпишите Ubuntu Code of Conduct. Всё это хорошо описано здесь: http://ky6uk.ugatu.net/launchpad-its-really-simple, повторять не буду. Там же посмотрите, как создать ppa через web-интерфейс launchpad.

3. Публикация пакета на launchpad

Дело за малым: опубликовать пакет. Пока что мы работает с готовыми пакетами, поэтому директория debian уже присутствует, осталось только внести необходимые изменения. Я делал (с gThumb) так:
Взял с официального сайта архив gthumb-2.11.3.tar.gz (если там будет tar.bz2 - придётся переупаковать).
Распаковал архив в рабочую директорию и переименовал архив в gthumb_2.11.3.orig.tar.gz (обратите внимание на нижнее подчёркивание!)
Взял директорию debian из этого репозитория: git://git.debian.org/git/collab-maint/gthumb.git
Обновил debian/changelog - добавил
gthumb (3:2.11.3-0divius1~lucid0) lucid; urgency=low

* New upstream release:
- ftp://ftp.gnome.org/pub/GNOME/sources/gthumb/2.11/gthumb-2.11.3.news
- 05-fix_locales.patch disabled due to translations update
- 06-add_keybinding_DoNotSave.patch disabled to translations update
- 18-build_with_gtk2.19.patch disabled, no longer required

-- Dmitry Tantsur <[email protected]> Wed, 21 Apr 2010 22:06:12 +0400


Теперь надо создать пакет с исходным кодом:

1 2	$ cd gthumb-2.11.3 $ debuild -S

Часто при этом debuild не включает в пакет сами исходники. Это хорошо, если мы уже собирали такой пакет, но плохо, если мы делаем это в первый раз - launchpad не найдёт исходники. Смотрим:



Да, исходников тут нет (не упоминается gthumb-2.11.3.orig.tar.gz). В моём случае сборка прошла успешно (файл уже присутствовал на launchpad), но в другой раз мне пришлось заставлять debuild собирать полный пакет:

1	$ debuild -S -sa

Всё! Осталось отправить пакет на launchpad:

1	$ dput ppa:divius/ppa gthumb_2.11.3-0divius1~lucid0_source.changes

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

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