>это не то, там проблемы с конкретными (+неофициальными) пакетами.

Тем не менее, с учетом этих фактов, deb выглядит не менее геморным, чем rpm.

>>>после которого мне приходилось это делать уже постоянно, т.к. rpm отказывался иногда ставить пакеты ссылаясь на битость базы.

>>ну явная чушь.

ну да, конечно.

>в оном нет базы. И всего цимеса с ней связанного.

Зато есть падающие prerm и postrm-скрипты. Тоже доставляют :)

Сегодня прямо день отличных новостей. То новелл порадовал, теперь дебьян :-)

За что люблю Дебиан, что не торопятся всякую фигню принимать. А значит можно не бояться почти неприятных сюрпризов с новыми велосипедами.. следовательно и Убунту всегда будет приемлимо работать. А вот расскажу внукам, что застал ЛОР без анонимов и почти без мусора, не поверят..

Debian заимствует всё лучшее из Gentoo?

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

И замедляет зеркалирование.

>> вы все мудаки, новость не читал, дебиан - лучший!

> так толсто провоцируешь чтобы анонимусов забанили? утешься сын мой, тебя забанят по айпи а анонимусов не забанят.

А мне понравилось. :)

> Ранее проект Ubuntu уже принял этот формат в качестве основного, не дожидаясь его официального признания Debian'ом.

4.2. В той новости речь совсем о другом, а формат orig.tar.gz/debian.tar.gz до сих пор Launchpad'ом не поддерживается.

Правильно. Хомячки из быдлоубунты тестируют, а мы потом нормально пользуемся.

Правильно говоришь. Хорошая новость!

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

Спешите видеть. Только на ЛОРе. Тролль на тролле и троллем погоняет!

>Спешите видеть. Только на ЛОРе. Тролль на тролле и троллем погоняет!

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

>Зато есть падающие prerm и postrm-скрипты. Тоже доставляют :)

тож такое есть. Зачем такие сложные интерактивные сценарии городить - мне непонятно.

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

В квотес! Однозначно! Анонимусы форева!

Ты! Куй! Война не будет ждать, да :)

Когда я был маленьким и сидел на Слаке, мне были непонятны такие проблемы. С переходом на Дебиан все стало по-другому. Тут пакеты конечно да - маленькие, кучами, и с зависимостями. В Слаке написать пакет - тьфу, а за deb даже браться жутковато.

Ололо! Они изобрели SRPM.

В принципе дебиан умеет работать с rpm/srpm-пакетами, но я их не пробовал ставить - как-то не было необходимости. И, кстати, есть ли хаутушка по сборке rpm-пакетов?

Как видно, в треде большинство комментирующих про единый .diff.gz этот самый .diff.gz в глаза не видело.

В .diff.gz можно хранить любую структуру директорий, в том числе и те же самые раздельные debian/patches, управляемые с помощью quilt/dpatch/simple-patchsys и т.д., что и делалось в большинстве пакетов с более чем одним патчем.

С debian'ом больший жесткач был. Если через apt-get прилетает кривой пакет (а с woody, особенно r0, такое было неоднократно), то всё, apt-get ом его уже не снесешь и новое ничего не поставишь. И приходиться руками разгребать чего оно наворотило.

Главное, что бы впустую работу не делали, а так - молодцы. И то, что Ubuntu впереди планеты всей тоже здорово.

Debian объявляет об официальной поддержке DebSrc3.0

И, кстати, есть ли хаутушка по сборке rpm-пакетов?

Вот, держи. Тут не только про rpm.

http://linuxforum.ru/index.php?showtopic=76757
http://welinux.ru/post/1854/
http://www.linux.org.ru/view-message.jsp?msgid=4194573&lastmod=1257232178819
http://tigro.info/blog/index.php?id=375
http://gq.net.ru/2007/03/16/building-deb-packages/

Спасибо!

Спасибо. Добавил на будущее в закладки (rpm-ки по tigro собирать приходилось, а deb-ки еще нет).

Я думаю, что версия 4 уже будет просто RPM, но совместимая с deb :)))))))))))))

Правильной дорогой идете дорогие товарищи!

>>Формат пакета deb как раз самый простой и правильный: control.tar.gz + data.tar.(gz|bz2|lzma), упакованные в ar-архив.

>Пакет deb - переименованный архив, в котором содержаться ещё два архива, в которых лежат ещё по несжатому архиву. Всё это работает с утилитами, пришедшими из UNIX в 80-х годах.

Да,и к тому же не подписанный. :(
Что позволяет делать атаки через mirror :(((((((((((((((((((

Еще один гвоздь в крышку RPM!

Бгггг, впереди планеты всей... Понабежало тут эстонских анабиозников на лор!...

> Хотелось бы почитать здесь мнения людей, которые пользуются данным дистрибутивом, а не бессмысленную перепалку анонимусов. К ответу, дебианщики :)

А нам пофиг. Если разработчикам удобнее - пусть используют. Для пользователя все останется по старому.

>>или слетаниях базы установленных пакетов связано именно с rpm-based (как там, rpm --rebuilddb?

это встречалось только в альте

Это было и в сусе и в шапке временами. По крайней мере когда я ими пользовался лет 6-9 назад.

>Пакет deb - переименованный архив, в котором содержаться ещё два архива, в которых лежат ещё по несжатому архиву. Всё это работает с утилитами, пришедшими из UNIX в 80-х годах.

Дебиан! Чудеса велосипедостроения у вас дома!

Дурачок. это UNIX-WAY. А вот если бы ты придумал новый мегаархиватор чтобы это все хранить - то это и был бы велосипед.

Запрашивает Миша Рыцаревъ

Интересно, а как изменится совместимость всего этого со старым железом? Хуже или лучше станет? А какие изменения в функционале и поведении ОС будут еще? Можно-ли будет внести эти изменения без переустановки ОС? Возможно-ли появление этого и в недебиановских дистрибутивах? Когда все это появится?

> Интересно, а как изменится совместимость всего этого со старым железом?

А она должна измениться?

Можно-ли будет внести эти изменения без переустановки ОС?

Поддерживается (и - насколько я понял - уже «не один день») и 2.0, и 3.0.

Возможно-ли появление этого и в недебиановских дистрибутивах?

Вы читали новость?

Вообще-то, отдельные патчи и сейчас есть. Они и давно были. Поддерживаются через quilt/dpatch. Патчи можно обнаружить в /debian/patches (если, разумеется, сопровождающий именно таким образом патчит исходники). Если бы апстрим захотел бы глянуть патчи, то он должен был скачать исходники (orig.tar.gz, diff.gz и .dsc), распаковать их через dpkg-source и залезть в /debian/patches.

Вот, к примеру, /debian/patches из icewm

00list                    i18n_updates.dpatch        package_build_fixes.dpatch
compiler_defaults.dpatch  iconify_on_wm_hint.dpatch  tray_hotfixes.dpatch
cvs_fixes.dpatch          misc_fixes.dpatch
debian_defaults.dpatch    move-to-screen.dpatch

Насколько я понимаю, просто поменяли способ хранения. Т. е. достаточно будет распаковать debian.tar.*, чтобы получить каталог /debian с патчами. И теперь каталог /debian не будет находиться внутри исходного кода, а будет уровнем выше, а исходных кодов (разных версий upstream) может быть уже несколько, т.е . несколько orig.tar.gz.

В SRPM, если я правильно понимаю, патчи и оригинал идут в одном файле. Разные файлы в Debian дают очевидные выгоды. Это отличается от того, что сделано в SRPM.

>а исходных кодов (разных версий upstream) может быть уже несколько, т.е . несколько orig.tar.gz.

Только не разных версий, а просто если апстрим исходники одной версии в нескольких тарболах отдает (такое встречается).

сравнил. в хауту про дебки написано только, как готовую дебку пересобрать в другом дистре. А, еще ченжлог поменять. Это в объеме текста, которого для рпм хватит, чтобы по простому, на примере, объяснить сборку пакета с нуля.

В SRPM, если я правильно понимаю, патчи и оригинал идут в одном файле. Разные файлы в Debian дают очевидные выгоды. Это отличается от того, что сделано в SRPM.

$ rpmdev-extract polipo-1.0.4-1.src.rpm

warning: polipo-1.0.4-1.src.rpm: Header V3 DSA signature: NOKEY, key ID 91df7ddd
polipo-1.0.4-1.src/polipo-1.0.4.tar.gz
polipo-1.0.4-1.src/polipo-allowHttpUnknown.patch
polipo-1.0.4-1.src/polipo-makefile.patch
polipo-1.0.4-1.src/polipo.config
polipo-1.0.4-1.src/polipo.forbidden
polipo-1.0.4-1.src/polipo.init
polipo-1.0.4-1.src/polipo.spec

Патчи отдельно, исходник отдельно. Что не так?

> Это в объеме текста, которого для рпм хватит, чтобы по простому, на примере, объяснить сборку пакета с нуля

Не знаю, сколько там для дебок, но когда мне надо было собрать один пакет, которого не было в дистре (вышеприведенный polipo), осилил с нуля за полдня, но полностью хаутушки не читал, страшно ^^ Хоть и сборка получилась крайне наколеночная, но работает и ладно, все равно только для себя.

В своё время отказался от муторного dpkg для embedded систремы в пользу простого pacman, и ни разу не пожалел.

Слишком муторно с этим dpkg, лишний пробел в спеке поставишь, и вот уже нифига не собирается, причем описание ошибки совершенно не даёт представления, что не так.

>Патчи отдельно, исходник отдельно. Что не так?

Все так, кроме того, что патчи и исходники запакованы в один src.rpm. Я об этом и говорю. В Debian изменения и исходник из апстрима распространяются в двух отдельных файлах orig.tar.gz и diff.gz. Сейчас будут в виде orig.tar.* и debian.tar.*

>осилил с нуля за полдня

Это называется быстро и удобно. Свой первый PKGBUILD я за 5 минут написал, после просмотра примера. С deb возился половину дня, в конце концов, результат тоже показался мне сделаным через жопу.

>В SRPM, если я правильно понимаю, патчи и оригинал идут в одном файле. Разные файлы в Debian дают очевидные выгоды. Это отличается от того, что сделано в SRPM.

в srpm все исходники и патчи уложены в один cpio. А тут (теперь) в один ar. Вся разница.

Это только для тех, у кого исходник уже есть, а патчи посмотреть охота, и при этом не качать еще и исходник, получается? Область применения как-то узковато выглядит для неспециалиста.

Плюс тогда надо уже и новое описание патчей юзать, как тут новость была, чтобы точно определить, к какой именно версии исходников патч. А то потом разбираться может быть намного больший гемор же.

Ах да, еще догадались иерархию debian/* вынести из тарбола с исходниками. А то непонятно, если тарболов несколько, в каком из них искать всю эту управляющую тряхомудию по сборке пакета

> Свой первый PKGBUILD я за 5 минут написал, после просмотра примера. С deb возился половину дня, в конце концов, результат тоже показался мне сделаным через жопу.

Ну логично — системы, ориентированные на установку из сорцов, имеют простую и понятную систему для этого. А для пакетников локальная сборка пакета всё-таки далеко не рядовая задача же. Что примерно компенсируется легкостью и скоростью yum update вместо emerge world.

>Это только для тех, у кого исходник уже есть, а патчи посмотреть охота, и при этом не качать еще и исходник, получается? Область применения как-то узковато выглядит для неспециалиста.

да ни разу. для этих придумано хранить патчи и все такое в git.

Это для тех, кто хочет скачав пакет быстро понять, что там за патчи, сколько их и что изменилось. Прозрачности больше.

>А для пакетников локальная сборка пакета всё-таки далеко не рядовая задача же.

с RPM эта нерядовая задача решается за 15 минут.

>Ололо! Они изобрели SRPM.

Не, весь смысл этих изменений — это улучшение по сравнению с предыдущей версией хранения исходных кодов. Изменения не революционные, а эволюционные. Цели и улучшения описаны выше по ссылкам, но уже по ним видно, что они касаются в кое-каких улучшений в тех местах, которые раздражали.

Кое-какие различия между тем, как было и как будет, выше по ссылкам. Человек, который делает srpm не поймет, что там улучшилось, так как все улучшения касаются инфраструктуры Debian, а не появлению каких-то новых принципов в пакетостроении.