Ubuntu Lucid принимает на вооружение новый формат пакетов исходного кода

Круто! Научиться бы еще самому с легкостью дебы собирать. Если кто занимается сборкой - по каким мануалам учились и какие инструменты облегчающие сборку используете?

Вообще поражает, сколько костылей наверчено в системе сборки deb. rpm собирать намного проще

Где там костыли? .deb это ar-ахив с преодпределённой структурой. Всё остальное - лишь скрипты, упрощающие создание этой предопределённой структуры, никто не мешает написать свои, например.

С новым форматом костылей поубавится. Системы патчей (dpatch, simple-patchsys, quilt) как раз были одним из костылей, от которых теперь можно отказаться.

Круто! Научиться бы еще самому с легкостью дебы собирать. Если кто занимается сборкой - по каким мануалам учились

http://wiki.ubuntu.com/PackagingGuide

> Где там костыли?

В системе сборки.

.deb это ar-ахив с преодпределённой структурой.

Спасибо, Капитан.

Согласен, собрать деб-пакет порой дело не из лёгких. Те же пакеты у арча собираются во много раз быстрее с использованием лишь PKGBUILD'a и одной команды - makepkg.

> В системе сборки.

4.2
просто рпмщикам неудобно было патчи выколупывать и сырцов.

Они снова изобрели rpm?

> Вообще поражает, сколько костылей наверчено в системе сборки deb. rpm собирать намного проще

самые простые и удобные в сборке пакеты арча. pkgbuild'ы очень просто писать, даже проще, чем пакеты в pkgsrc

>с легкостью дебы собирать

o_0 вообще-то сборка deb пакетов одна из самых сложных (если не самая)

> Вообще поражает, сколько костылей наверчено в системе сборки deb. rpm собирать намного проще

Типичное мнение того, кто собрал один раз rpm-ку из 2-х файлов. Если бы вы собирали пакеты для серьёзных проектов со сложной структурой, вы бы поняли, насколько всё в deb проще. А так, конечно... Deb - unix-way. Сложно, но гибко. Rpm - наоборот. Кажется простым, но в результате в сложном проекте, который я писал, я от него отказался. Усилия не оправдываются.

> o_0 вообще-то сборка deb пакетов одна из самых сложных (если не самая)

Для кого ? ))

>самые простые и удобные в сборке пакеты арча

самые простые - слакбилды =)

> Deb - unix-way. Сложно, но гибко.

С dh 7 - это скорее как cmake. Простые случаи делаются в две строки (ладно, с шебангом - в три), сложные - сложно, но логика всё равно прослеживается.

>Для кого ? ))

Корректный вопрос не для кого, а по сравнению с чем. По сравнению со всеми остальными.

Нет, если не читать документацию - все сложно.
А залетным там по быреньку порыться, плюнуть и вынести вердикт - таким всегда будет сложно.

зачет автор новости

без последнего предложения тут бы уже было 9 страниц флуда на тему «БИДА! БИДА! ЛАМАЮТ СОВМЕСТИМОСТЬ!!!111»

> Если бы вы собирали пакеты для серьёзных проектов со сложной структурой, вы бы поняли, насколько всё в deb проще

Для собрки deb-пакета нужно написать 4 файла (про крышесносящий формат этих файлов пока промолчим), версия указывается независимо в двух или трёх местах, с патчами отдельная песня. В rpm – один файл, нсе все описано единым синтаксисом. Вобщем, пургу несете, уважаемый.

Объективно сложнее. Одна только необходимость следить за отступами с точностью да каждого пробела чего стоит (ну какой придурок такое выдумал?)

> с патчами отдельная песня.

Ну пропой эту песню а то, что-то скучно совсем.

> Для собрки deb-пакета нужно написать 4 файла (про крышесносящий формат этих файлов пока промолчим)

Строго говоря, три.copyright продиктован лицензионными, а не техническими соображениями.

«Крышесносящий» формат только у changelog (который всё равно генерируется dch) и control. rules - обычный Makefile, который для простых пакетов может состоять таки из трёх строк. К тому же не нужно генерировать всю структуру с нуля, есть dh_make.

версия указывается независимо в двух или трёх местах

В changelog. И... в changelog. Где ещё-то?

с патчами отдельная песня

Какая отдельная песня? Патчи в debian/patches. С новым форматом пакетов даже quilt для сборки не нужен.

> Объективно сложнее. Одна только необходимость следить за отступами с точностью да каждого пробела чего стоит (ну какой придурок такое выдумал?)

Думаю, что вам нравится питон.

> Объективно сложнее. Одна только необходимость следить за отступами с точностью да каждого пробела чего стоит (ну какой придурок такое выдумал?)

А необходимость следить за регистром букв в именах файлов/переменных — какой придурок придумал? Windows и Visual Basic — ничего лучше пока нет

Вообще, кто придумал необходимость следить? Я доверяю своим троянам

>> В системе сборки.

4.2

Доо.

просто рпмщикам неудобно было патчи выколупывать и сырцов.

Просто рпмщики смотрят на систему спорки .deb как на гов^W^W^Wтак, как она того заслуживает. RPM в разы проще и логичнее.

>o_0 вообще-то сборка deb пакетов одна из самых сложных (если не самая)

ТУПО собрать очень легко, легче чем рпм. Создается каталог, делается в нем usr/, в него все что надо установить, в том же каталоге делается каталог debian, в него кидается control с описанием программы и зависимостей (образец вытягивается из любого попавшего под руку деба). Да льше cd ../.. и dpkg-deb .

Но в репы такое не возьмут, так как линтиан матерится

> RPM в разы проще и логичнее.

Хо хо, он еще и брыкается !! ))

Простоватый зоопарк из костылей - это круто, да.

> Простоватый зоопарк из костылей - это круто, да

Браво. Идеальная характеристика инструментов сборки .deb

> Создается каталог, делается в нем usr/, в него все что надо установить, в том же каталоге делается каталог debian, в него кидается control с описанием программы и зависимостей (образец вытягивается из любого попавшего под руку деба). Да льше cd ../.. и dpkg-deb .

А в лоб?!

«В репы такое не возьмут» не из-за Линтиана, а из-за того, что это несовместимо вообще со всем процессом сборки. Я сама так делала, но это *сложнее*, чем делать пакеты по науке, через пакеты исходников.

control в бинарном пакете должен генерироваться из исходного. Иначе запаритесь все зависимости прописывать. А вообще - хотя бы распакованная директория исходников с папкой debian. Из неё и dsc собрать можно.

> «Крышесносящий» формат только у changelog (который всё равно генерируется dch) и control. rules - обычный Makefile

Вот мне, если честно, этот Makefile как раз в первую очередь не по душе.

В changelog. И... в changelog. Где ещё-то?

В debian.control и в .dsc разве не надо?

Какая отдельная песня? Патчи в debian/patches

Ага, только каталог этот засунут в diff-файл (патч, содержащий патчи, офигеть!). Не добавлять же дистрибутивные патчи в архив с исходниками?

Кстати, и всякие там .rules etc. тоже в том же .diff-файле запакованы. При таком подходе добавить одну строчку в .rules – настоящее приключение.

> Думаю, что вам нравится питон.

Нравится. Там регламентирован лишь сам факт наличия отступов, а не их величина. Да и внутри строки пробелов ставить можно сколько угодно.

Ага, только каталог этот засунут в diff-файл (патч, содержащий патчи, офигеть!).

Вот пакет, только что переведённый мной на новый формат: http://archive.ubuntu.com/ubuntu/pool/universe/f/fuse-zip/

Обратите внимание, что у старого формата diff.gz, а у нового debian.tar.gz. Намёк понятен?

Кстати, и всякие там .rules etc. тоже в том же .diff-файле запакованы. При таком подходе добавить одну строчку в .rules – настоящее приключение.

dpkg-source -x, затем debuild -S. Работать вы всё равно будете с распакованной директорией, а если меняете чужой пакет - всё равно надо обновлять changelog и собирать новый dsc.

Для интересующихся выкладываю следующие три строки минимального debian/rules. Всё остальное делается с помощью правил override_dh_*.

#!/usr/bin/make -f
%:
	dh $@

>Нет, если не читать документацию - все сложно.

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

> В debian.control и в .dsc разве не надо?

В debian/control - нет. dsc генерируется автоматически при сборке.

> Нравится.

А мне нет.

а не их величина. Да и внутри строки пробелов ставить можно сколько угодно.

И что, это невероятная препона ?
Скопировать строку чейнжлога и вставить свои записи - офигеть как сложно !!.)

> Опять ты своей пиписькой махать пытаешься...

«разумно необходимый минимум знаний о пакетной системе для сборки пакета» - что-то попахивает тут студенческими лабами.

Для того, чтобы собрать deb этих знаний нужно больше, чем для остальных.

Ok.
Ладно , вообщем, меня устраивает это пугало и в таком виде - меньше будет дрянных и наспех сделанных пакетов.

> Обратите внимание, что у старого формата diff.gz, а у нового debian.tar.gz. Намёк понятен?

Ну я-то тут про старый формат троллю. С новым незнаком, вроде он немного логичнее.

Никто не мешает скачать один из существующих пакетов и подправть структуру под себя, если уж религия не позволяет использовать dh_make для генерации (а я его не люблю, он городит кучу ненужного мусора). Посмотрите тот же fuse-zip в lucid (ссылка выше) - чуть ли не сферический образчик минимального пакета в вакууме. Хотя бывают и ещё минимальнее.

А с существующими пакетами всё проще. Алгоритм такой:
- Скачать и распаковать текущую версию (apt-get source).
- Сделать изменения.
- Отметиться в debian/changelog, инкрементировать версию (dch).
- Собрать новый пакет-исходник. (debuild -S) Можно собрать и deb - debuild -b.
- Залить в дистрибутив (dput).

При этом dsc, changes, diff.gz/debian.tar.gz и иже с ними генерируются сами. Версия пишется в одном месте - в самой последней записи в debian/changelog.

> Скопировать строку чейнжлога и вставить свои записи - офигеть как сложно !!.)

И копировать не надо, разве что при мёрже из Дебиана. А так есть dch и uupdate.

А какая им разница ? )) - «замурована дверь» и все.

> Скопировать строку чейнжлога и вставить свои записи - офигеть как сложно !!.)

Кстати, идея хранить информацию для сборки в changelog'е тоже заслуживает упоминания как совершенно нелогичная. Видно, что тут приложили руку люди, ни черта не смыслящие в проектрировании. Собственно, только таким людям эта система сборки и может понравиться.

>на вооружение

формат пакетов исходного кода

Долго думал...

Чавоооо ? ))

ню ню , проектант наш:

1. положил патч в debian/patches,
2. и отметил это номером версии и причны в changelog
3. запустил debuild и получил на выхлопе все пакеты и новые сырцы.

причны -> причины и фиксы в changelog

inform (6.31.1+dfsg-1ubuntu1) lucid; urgency=low

  * Removed alternatives configuration. (LP: #411523)

 -- Maia Kozheva <sikon@ubuntu.com>  Wed, 16 Dec 2009 19:21:35 +0600

Как раз наоборот, при той инфраструктуре, которая для сборки используется - вполне логично. Только подумайте, сколько информации сконцентрировано в одной записи changelog'а наподобие этой.

- Номер версии. - Релиз дистрибутива, в который нужно залить пакет. - Дата изменений. - Имя и емэйл виновника торжества. - Исправленные баги.

И вся эта информация извлекается и используется автоматически. Можно, конечно, её дублировать где-то ещё, но ЗАЧЕМ? Так действует принцип «не повторяй себя».

На самом деле всё упирается в то, что дистрибутив - этакая недо-VCS, работающая по схеме «одна версия пакета = один коммит». Как и полагается коммиту, у версии пакета есть номер, автор, дата, дифф к предыдущей версии итэдэ. Вот только при попытке увязать весь этот зоопарк утилит с настоящей VCS получаются настоящие костыли типа svn-buildpackage/git-buildpackage/etc и настоящие грабли. Нет, даже так: Грабли. С большой буквы Г.

> И вся эта информация извлекается и используется автоматически. Можно, конечно, её дублировать где-то ещё, но ЗАЧЕМ? Так действует принцип «не повторяй себя».

И да, changelog файлы доступны apt напрямую и можно проследить изменения ( а уровень подробностей - тут уже от добросовестности сопровождающего пакета зависит)

>Ладно , вообщем, меня устраивает это пугало и в таком виде - меньше будет дрянных и наспех сделанных пакетов.

Доказано Убунтой (?) :)

>Круто! Научиться бы еще самому с легкостью дебы собирать. Если кто занимается сборкой - по каким мануалам учились и какие инструменты облегчающие сборку используете?

Мне для старта хватило созерцания существующих пакетов и гугла.

> Доказано Убунтой (?) :)

А что Ubuntu ?
Косяки софта от пакетной системы уже не отличаем ?

> Доказано Убунтой (?) :)

Таки да, доказано.

Требования к структуре пакетов весьма строгие в обоих дистрибутивах, и в том числе именно поэтому их пакеты так хорошо интегрируются друг с другом.

По сравнению со строгостью Debian Policy и Lintian'а официальные дебы для Google Chrome и инфра-ресурсовского OOo, ставящие всё в /opt, кажутся поделками кружка юных техников.