LINUX.ORG.RU

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

 , , ,


0

0

19 декабря серверы сборки Launchpad, используемые для разработки Ubuntu, получили поддержку новых форматов пакетов исходного кода, ранее включённых в Debian Squeeze - 3.0 (native) и 3.0 (quilt). Несколько пакетов в новых форматах уже загружены в нестабильную версию Ubuntu - 10.04 (Lucid).

Для разработчиков пакетов эта новость означает, что теперь управление системой патчей в составе пакета встроено прямо в утилиты сборки dpkg, а также появилась возможность использовать для создания пакета архивы tar.bz2 без предварительной перепаковки в tar.gz. В новом формате также отказались от хранения изменений пакета в виде сжатого diff - теперь ему на смену пришёл архив debian.tar.gz, что позволяет разработчикам пакета включать свои бинарные файлы без предварительного перекодирования в текст.

Описание новых форматов можно найти на http://wiki.debian.org/Projects/DebSr... .

С точки зрения конечного пользователя ничего не изменяется - формат бинарных deb-пакетов остаётся нетронутым.

>>> Подробности

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

Soulreader ()

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

MadCAD ★★ ()
Ответ на: комментарий от MadCAD

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

Legioner ★★★★★ ()
Ответ на: комментарий от MadCAD

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

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


http://wiki.ubuntu.com/PackagingGuide

LucidFox ()
Ответ на: комментарий от Legioner

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от MadCAD

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

dark_lord ()
Ответ на: комментарий от tailgunner

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

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

elipse ★★★ ()

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

anonymous ()
Ответ на: комментарий от MadCAD

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

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

val-amart ★★★★★ ()
Ответ на: комментарий от Soulreader

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

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

frame ★★★ ()
Ответ на: комментарий от MadCAD

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

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

anonymous ()
Ответ на: комментарий от frame

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

Для кого ? ))

elipse ★★★ ()
Ответ на: комментарий от val-amart

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

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

frame ★★★ ()
Ответ на: комментарий от anonymous

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

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

LucidFox ()
Ответ на: комментарий от elipse

>Для кого ? ))

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

frame ★★★ ()
Ответ на: комментарий от frame

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

elipse ★★★ ()

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

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

rudchenkos ()
Ответ на: комментарий от anonymous

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

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

anonymous ()
Ответ на: комментарий от elipse

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

elipse ★★★ ()
Ответ на: комментарий от anonymous

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

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

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

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


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

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


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

LucidFox ()
Ответ на: комментарий от anonymous

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

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

elipse ★★★ ()
Ответ на: комментарий от anonymous

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

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

ubuntulover ()
Ответ на: комментарий от ubuntulover

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

ubuntulover ()
Ответ на: комментарий от elipse

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

4.2

Доо.

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от frame

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

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

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

annulen ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

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

elipse ★★★ ()
Ответ на: комментарий от elipse

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от annulen

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

А в лоб?!

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

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

LucidFox ()
Ответ на: комментарий от LucidFox

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от elipse

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

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

anonymous ()
Ответ на: комментарий от anonymous

Ага, только каталог этот засунут в 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 $@
LucidFox ()
Ответ на: комментарий от elipse

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

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

frame ★★★ ()
Ответ на: комментарий от anonymous

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

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

LucidFox ()
Ответ на: комментарий от anonymous

> Нравится.

А мне нет.

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


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

elipse ★★★ ()
Ответ на: комментарий от frame

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

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

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


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

elipse ★★★ ()
Ответ на: комментарий от LucidFox

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

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

anonymous ()
Ответ на: комментарий от frame

Никто не мешает скачать один из существующих пакетов и подправть структуру под себя, если уж религия не позволяет использовать 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.

LucidFox ()
Ответ на: комментарий от elipse

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

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

LucidFox ()
Ответ на: комментарий от LucidFox

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

elipse ★★★ ()
Ответ на: комментарий от elipse

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

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

anonymous ()

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

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


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

iZEN ★★★★★ ()
Ответ на: комментарий от anonymous

Чавоооо ? ))

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

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





elipse ★★★ ()
Ответ на: комментарий от anonymous
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 и настоящие грабли. Нет, даже так: Грабли. С большой буквы Г.

LucidFox ()
Ответ на: комментарий от LucidFox

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

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

elipse ★★★ ()
Ответ на: комментарий от elipse

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

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

frame ★★★ ()
Ответ на: комментарий от Soulreader

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

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

Pavval ★★★★★ ()
Ответ на: комментарий от frame

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

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

elipse ★★★ ()
Ответ на: комментарий от frame

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

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

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

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

LucidFox ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.