divius 25.04.2010 16:55

How-to`sPPA своими руками с нуля. Часть 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 <sanvila@debian.org>
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:

$ cat gthumb/debian/control
Source: gthumb
Section: gnome
Priority: optional
Maintainer: David Paleino <dapal@debian.org>
Build-Depends: debhelper (>= 7.0.50~),
intltool,
libexiv2-dev (>= 0.18),
flex,
libtiff4-dev,
libpng12-dev,
libjpeg62-dev,
gconf2,
scrollkeeper,
automake,
autoconf,
quilt (>= 0.46-7~),
libtool,
gnome-doc-utils,
gnome-common,
libgtk2.0-dev (>= 2.16.0),
libgconf2-dev (>= 2.6.0),
libxml2-dev (>= 2.4.0),
libglib2.0-dev (>= 2.16.0),
libcairo2-dev,
libltdl3-dev,
libiptcdata0-dev,
libglade2-dev (>= 2.4.0),
libgstreamer0.10-dev (>= 0.10),
libgstreamer-plugins-base0.10-dev,
libunique-dev (>= 1.1.2),
libsoup-gnome2.4-dev (>= 2.26),
libgnome-keyring-dev (>= 2.28)
Standards-Version: 3.8.4
Homepage: http://gthumb.sourceforge.net
Vcs-Git: git://git.debian.org/git/collab-maint/gthumb.git
Vcs-Browser: http://git.debian.org/?p=collab-maint/gthumb.git

Package: gthumb
Architecture: any
Depends: ${shlibs:Depends},
${misc:Depends},
gthumb-data (= ${source:Version})
Recommends: gvfs-bin
Conflicts: gthumb2
Provides: gthumb2
Replaces: gthumb2
Description: an image viewer and browser
gThumb is an advanced image viewer and browser. It has many useful
features, such as filesystem browsing, slide show, image catalogs, web
album creation, camera import, image CD burning, batch file operations and
quick image editing features like transformation and color manipulation.
.
It's designed for GNOME 2 desktop environment and uses its platform. For
camera import feature, the gPhoto2 library is used.

Package: gthumb-dbg
Architecture: any
Section: debug
Priority: extra
Depends: ${misc:Depends},
gthumb (= ${binary:Version})
Description: an image viewer and browser - debugging symbols
gThumb is an advanced image viewer and browser. It has many useful
features, such as filesystem browsing, slide show, image catalogs, web
album creation, camera import, image CD burning, batch file operations and
quick image editing features like transformation and color manipulation.
.
It's designed for GNOME 2 desktop environment and uses its platform. For
camera import feature, the gPhoto2 library is used.
.
This package contains the debugging symbols for gThumb.

Package: gthumb-data
Architecture: all
Conflicts: gthumb (<< 3:2.10.8-1)
Replaces: gthumb (<< 3:2.10.8-1)
Recommends: yelp
Depends: ${misc:Depends},
scrollkeeper
Description: an image viewer and browser - arch-independent files
gThumb is an advanced image viewer and browser. It has many useful
features, such as filesystem browsing, slide show, image catalogs, web
album creation, camera import, image CD burning, batch file operations and
quick image editing features like transformation and color manipulation.
.
It's designed for GNOME 2 desktop environment and uses its platform. For
camera import feature, the gPhoto2 library is used.
.
This package contains the architecture-independent files needed by gthumb.

Package: gthumb-dev
Architecture: any
Section: devel
Depends: ${misc:Depends},
gthumb (= ${binary:Version})
Description: an image viewer and browser - development files
gThumb is an advanced image viewer and browser. It has many useful
features, such as filesystem browsing, slide show, image catalogs, web
album creation, camera import, image CD burning, batch file operations and
quick image editing features like transformation and color manipulation.
.
It's designed for GNOME 2 desktop environment and uses its platform. For
camera import feature, the gPhoto2 library is used.
.
This package contains the files needed to develop third-party extensions.


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

Отдельно стоит рассмотреть секцию 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 будет заменено на соответствующую архитектуру.

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

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


И последнее важное замечание: обратите внимание, что в файле 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 <divius.inside@gmail.com> 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 <dapal@debian.org> 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 <divius.inside@gmail.com>
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 <divius.inside@gmail.com> Wed, 21 Apr 2010 22:06:12 +0400


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

1
2
$ cd gthumb-2.11.3
$ debuild -S



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

$ cat gthumb_2.11.3-0divius1~lucid0_source.changes
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Wed, 21 Apr 2010 22:06:12 +0400
Source: gthumb
Binary: gthumb gthumb-dbg gthumb-data gthumb-dev
Architecture: source
Version: 3:2.11.3-0divius1~lucid0
Distribution: lucid
Urgency: low
Maintainer: David Paleino <dapal@debian.org>
Changed-By: Dmitry Tantsur <divius.inside@gmail.com>
Description:
gthumb - an image viewer and browser
gthumb-data - an image viewer and browser - arch-independent files
gthumb-dbg - an image viewer and browser - debugging symbols
gthumb-dev - an image viewer and browser - development files
Changes:
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
Checksums-Sha1:
f60d20505adb9106f2442b09f8c34f4e97268e87 1778 gthumb_2.11.3-0divius1~lucid0.dsc
0ed06ef9bb1107f2794573f41ae7777b53542237 4131518 gthumb_2.11.3-0divius1~lucid0.tar.gz
Checksums-Sha256:
61e8a0dedf291ff5de9cbd744f2eadab7ae60ab6063cfa86897aef7088232fcb 1778 gthumb_2.11.3-0divius1~lucid0.dsc
0ab103331d1287fc26bf6973de9027c3ed8763c53c8127c12ec67a26c388a81a 4131518 gthumb_2.11.3-0divius1~lucid0.tar.gz
Files:
ef6b9d0859152c59e29a3daadff61110 1778 gnome optional gthumb_2.11.3-0divius1~lucid0.dsc
22460bec221ec179db34b93aad30c222 4131518 gnome optional gthumb_2.11.3-0divius1~lucid0.tar.gz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQEcBAEBAgAGBQJLz1DfAAoJEE0x+5Glk/Fc21wH+gO06wSAfmq9tYZ405dBkfOK
sCb77yUrkQfa2ubUHk/usD17W19HTJpGP9ENyOEA+/Jx0wHHhQJ4zu7EUNDWFm5d
2NxP7NhPaLWA0AUTdH0UCXQeu0Db8B9sIo+hMlgpAnxKqA29XrE0GRoyBHR/aMR7
pBqzSsshHq4vZC756Oekm6JetPpsyU3oB/J4JZAvnDCqFMDRFWWy0UIFY7+8rsJa
HfDHgpP8hQ36+dqkh8/L4BU4CKRx3RuquIgljcdyl1qEqdyfJ517EH7JSARCuKVn
IA8fvpnY1c4KDJrpLWem2Dw3qkQNvQMt3Jq8lGCV9tdoh2GBBZkL68EfO8TGLw0=
=ZzN0
-----END PGP SIGNATURE-----


Да, исходников тут нет (не упоминается 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. Теперь вам на почту должно прийти письмо, в котором будет сказано, принял ли робот ваш пакет на сборку. После этого остаётся только ждать.

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


Тэги: deb debian ppa ubuntu
+ 13 -
Похожие Поделиться

Username 25.04.2010 17:13 #
Кто-нибудь, закиньте ссылочку на этот пост на хабр.
bosha 25.04.2010 21:31 #
Именно на этот, или может на оба? :)
divius 25.04.2010 21:40 #
Думаю, имеет смысл на оба
bosha 25.04.2010 21:42 #
Ммм.. Я могу, правда только в личный блог. В другие кармы не хватает (заминусовали). Если никого не появится с хорошей кармой и готового опубликовать, это могу сделать я :)
ner_uto 25.04.2010 21:38 #
Ссылку добавь чтоль во вводной на первую часть. А в первой - на продолжение.
divius 25.04.2010 21:40 #
done
bosha 02.05.2010 12:23 #
Так что ТС, публиковать на хабре, аль нет? :)
divius 02.05.2010 13:49 #
Да, почему бы и нет?
bosha 02.05.2010 14:09 #
Так как на хабре теперь запрещена копипаста, то отправлю ссылку на первый топик. Поставь на нём ссылку на продолжение если не сложно :)
divius 02.05.2010 14:17 #
вообще, она там была. поставил ещё одну, более явную
bosha 02.05.2010 14:29 #
Наверное как-то так - http://bosha.habrahabr.ru/blog/92610/

Если что пиши, исправлю\поправлю\дополню =>
divius 02.05.2010 15:17 #
Благодарю)
Murz 30.01.2011 21:55 #
Что-то не совсем понятно как туда исходники запихать, ведь скрипту наверно надо указать какие файлы класть в архив?
Вобщем пытаюсь сделать ppa с kosd. Качаю исходники отсюда: http://kde-apps.org/content/show.php?content=81457 и далее:
1. переименовываю архив в kosd_0.6.2.orig.tar.gz
2. распаковываю содержимое в папку kosd, переименовываю kosd-0.6.2, захожу в неё
3. запускаю dh_make, который создаёт папку debian и файлы в ней
4. меняю в файле control имя и email на свои (кстати, как через командную строку или по-умолчанию задать имя?), в changelog пишу версию 0.6.2-ppa1
5. пишу debuild -S -sa
Скрипт отрабатывает без ошибок (даже gpg-ключ находит, спрашивает пароль), создаёт файлы:
kosd_0.6.2.orig.tar.gz
kosd_0.6.2-ppa1.debian.tar.gz
kosd_0.6.2-ppa1.dsc
kosd_0.6.2-ppa1_source.build
kosd_0.6.2-ppa1_source.changes
kosd_0.6.2-ppa1_source.ppa.upload
kosd_0.6.2-ppa1_source.ubuntu.upload

Соответственно, в файле kosd_0.6.2-ppa1.debian.tar.gz должны быть исходники. Но когда в него захожу - вижу только папку debian в нём, а исходников нет.
Что я мог сделать не так?
Murz 31.01.2011 09:32 #
Вобщем с помощью бубна и такой-то матери удалось всё же залить пакет в свой PPA и он даже скомпилился! https://launchpad.net/~murznn/+archive/kde-osd

Мой пакет долго не хотел проходить проверку пока я не поправил версию со вставленной по-умолчанию
kosd (0.6.2-ppa4) unstable; urgency=low
на версию убунты:
kosd (0.6.2-ppa4) maverick; urgency=low

Укажите это в теме, а то наверно не я один на понимание этого пол дня потрачу ;)

Плюс ещё пара вопросов:

1. Для чего нужно оставлять архив kosd_0.6.2.orig.tar.gz если все те же исходники есть в папке kosd_0.6.2-ppa1?

2. Насколько я понял, версия берётся из файла changelog. Везде рекомендуют её писать через тильду - т.е. kosd_0.6.2~ppa1 но когда я так делаю, команда debuild говорит что архив с исходниками уже хочет не kosd_0.6.2.orig.tar.gz а kosd_0.6.2~ppa1.orig.tar.gz - почему так?
Murz 31.01.2011 09:34 #
Сорри, про имя дистрибутива проглядел - уже есть в теме ;)
divius 31.01.2011 21:13 #
Отвечаю на всё:
0. kosd_0.6.2-ppa1.debian.tar.gz не должен содержать ваши исходники, debuild всё правильно сделал=)
1. Потому что dput заливает orig.tar.gz, а не папку
2. Тильду добавляют после дебиановской версии, которая идёт после дефиса, например: 0.6.2-1~ppa1, а не 0.6.2~ppa1
Murz 01.02.2011 08:54 #
0. По поводу исходников - а если я что-то меняю сам, то я должен это всё дело сам же и заархивировать в orig.tar.gz? Я думал там хранится образец приложения, а я уже в папке ковыряю и вношу изменения которые мне надо.
По крайней мере вроде бы так выглядят архивы в репозиториях. Например, делаю apt-get source sudo:
# apt-get source sudo
Reading package lists... Done
Building dependency tree
Reading state information... Done
Need to get 803kB of source archives.
Get:1 http://ru.archive.ubuntu.com/ubuntu/ maverick-updates/main sudo 1.7.2p7-1ubuntu2.1 (dsc) <1,797B>
Get:2 http://ru.archive.ubuntu.com/ubuntu/ maverick-updates/main sudo 1.7.2p7-1ubuntu2.1 (tar) <772kB>
Get:3 http://ru.archive.ubuntu.com/ubuntu/ maverick-updates/main sudo 1.7.2p7-1ubuntu2.1 (diff) <29.3kB>
Fetched 803kB in 0s (1,266kB/s)
gpgv: Signature made Wed 19 Jan 2011 08:50:12 PM MSK using RSA key ID CC559573
gpgv: Can't check signature: public key not found
dpkg-source: warning: failed to verify signature on ./sudo_1.7.2p7-1ubuntu2.1.dsc
dpkg-source: info: extracting sudo in sudo-1.7.2p7
dpkg-source: info: unpacking sudo_1.7.2p7.orig.tar.gz
dpkg-source: info: unpacking sudo_1.7.2p7-1ubuntu2.1.debian.tar.gz
dpkg-source: info: applying makefile-strip.diff
dpkg-source: info: applying sudo-1.7.2p1-visudo-manpage-fix.diff
dpkg-source: info: applying typo-in-classic-insults.diff
dpkg-source: info: applying env.c-safety.diff
dpkg-source: info: applying paths-in-samples.diff
dpkg-source: info: applying sudoers.pod.diff
dpkg-source: info: applying sudo.pod.diff
dpkg-source: info: applying ubuntu-sudo-as-admin-successful.patch
dpkg-source: info: applying CVE-2010-2956.patch
dpkg-source: info: applying user_in_group.patch
dpkg-source: info: applying CVE-2011-0010.patch

Он берёт оригинал и накладывает патчи. Или же мне самому эти патчи надо будет ручками создавать и прописывать в скриптах чтобы накладывались?

1. А как же тогда мои патчи дойдут до сервера? ;))

2. Проблема в том, что у меня не дебиановская версия, а пакет с нуля, которого в deb я нигде не нашёл, поэтому и решил собрать сам. В данном случае я обязательно должен пронумеровать его как-то, например 0.6.2-1 или можно всё же 0.6.2 оставить?
divius 01.02.2011 17:32 #
1. Патчи лежат в директории debian, в поддиректории, кажется, patches, соответственно, они хранятся в debian.tar.gz. Подробнее гуглите, например, dpatch или (поновее) quilt
2. Дебиановская версия должна присутствовать. В вашем случае 0.6.2-1~что-то-там (т.к. версия с тильдой меньше версии без тильды)
Murz 02.02.2011 11:35 #
1. Т.е. вместо того чтобы самому что-то править в исходниках, лучше оригинал нетронутый оставить в файле .orig.tar.gz а к нему только патчи сверху свои добавлять надо? Вот блин геморрой какой, я думал скрипт сам при генерации сравнивает оригинал и изменения и делает патчи. Хотя quilt вроде бы как раз то что надо, пойду курить мануалы ;)

2. Т.е. не дебиановская а просто тупо ставлю 1 т.к. я первый такой кто собирает этот пакет, правильно?

И ещё вот возник вопрос: как мне туда залить пакет без исходников?
Например, я сделал универсальный словарь ru+en для myspell (чтобы вручную не переключать русский-английский), пакет содержит только пару готовых файлов в /usr/share и симлинки, компилить там нечего. Ставится через dpkg нормально, а вот на ppa как его задлить - никак не соображу ;(
Как его залить на ppa можно?
Murz 11.04.2011 20:23 #
В муках по сборке очередного пакета наткнулся на полезную тулзу для работы с файлами changelog - dch (debchange) - она автоматом записывает в файл имя, email, время и увеличивает версию.
Пользоваться очень просто: заходим в папку подготавливамого пакета и пишем
dch
она запустится и в превый раз спросит предпочитаемый редактор, а дальше уже не будет спрашивать.
Соответственно останется только список изменений заполнить, остальное уже будет заполнено.
Если вставляет не тот email, то его можно задать через переменную окружения DEBEMAIL:
export DEBEMAIL="Vasya Pupkin <vasya@example.com>"
Вставьте в статью эту инфу, другим тоже пригодится я думаю.
Murz 20.04.2011 12:17 #
Ещё тут вопрос возник - а можно сделать пакет, чтобы он сразу компилился под несколько версий Ubuntu?
Например под natty и maverick?
divius 20.04.2011 13:42 #
Компиляться-то он будет, разница будет только в Changelog.
Murz 20.04.2011 13:48 #
Так как раз вопрос в том как в changelog прописать это ;)
Вобщем вроде бы нашёл - http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Distribution - через пробел просто, вот так:
gthumb (3:2.11.3-0divius1~lucid0) lucid maverick natty; urgency=low