Перспективы RPM

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

Написал баг (по моему на yum), что не во всех случаях корректно устанавливаются exit codes и текст ошибки не всегда выводится в stderr. Из-за этого приходится парсить текст сообщения, который он выводит!

По поводу yum'a приведу еще пример: http://adedov.livejournal.com/10518.html

> А в чем заключается бесчеловечность?

В том, что нельзя создать графический frontend типа synaptic, где юзер сможет просто тыркнуть на кнопочки, выбрав тем самым те из рекомендованных зависимостей, которые ему покажутся нужными. Тем, что нельзя для frontend'а типа apt/yum сделать ключик "поставить со всеми мягкими зависимостями" и поиметь всё автоматом. В общем, тем, что придётся делать вручную то, что можно (и нужно) автоматизировать.

А твои варианты вполне искусственные. И перечитай остальной пост, пожалуйста.

> Покапался я тут в DEB. Честно скажу после RPM это просто страшно.

Было бы неплохо раскрыть как-то тему.

Создание rpm т.е. spec файла к простому пакету это 3 минуты и 10 строк самого спека.

С dpkg надо использовать кучу костылей (типа dh_make, dch,...) чтоб хоть как-то упростить работу. Да и все равно больше времени она занимает.

А любимая тема маинтайнеров Debian - сваливать все патчи в один. Это при живом dpatch. Пакеты пользующиеся dpatch по пальцам пересчитать можно. Зато у почти всех больших пакетов есть собственный велосипед-аналог dpatch.

deb очень даже неплох. Но сборка пакетов для него....

Сборка deb-пакетов достаточно проста. У вас жалобы странные - мэйнтейнеры де, собирают плохо, поэтому ужос. А это не так.

Это уже проблема сборщиков пакетов, к которым лично я не отношусь. Они не жалуются, вроде... Гораздо важнее, как оно в использовании.

Я после apt/deb совершенно не воспринимаю уже rpm, yum/rpm, apt/rpm, да и urpmi, который считал лучшим пакетным управлялщиком померк по сравнению с дебиановскими утилитами. Не претендуя на абсолютную истину, просто как-то так воспринимаю это.

ЗЫ собственно никто не мешает создать очередную супер-удобную систему сборки и поддержки deb-пакетов, дебианщики делают это регулярно. :) Никаких изменений в самом dpkg это не потребует.

apt-get install cdbs.
К этому медленно, но верно идут.

Ужос в том что нет разумного obsolete. И тянутся исторические несуразности уже очень долго.

Я не говорю что make это плохо. Но уже очень давно есть automake.

Просто deb очень низкоуровневый по сравнению с rpm. И это в 99% случаев не нужно. Нужны стандартные более высокоуровневые средства.

А расписать каждую операцию и в spec никто не мешает. Только это ну очень редко нужно.

> К этому медленно, но верно идут.

Медленно тут ключевое слово :) Слишком уже медленно.

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

Я не наблюдаю проблем с недостатком пакетов в Debian'е или Ubuntu. Точнее, таких проблем, вызванных непомерной сложностью создания пакетов. А как пользователя меня всё устраивает, и о какой низкоуровневости для пользователя может идти речь, я вообще не представляю.

А проблема сборки не имеет непосредственного отношения к dpkg/deb, она решается отдельными наборами утилит (причём таких наборов несколько). Возможно там и не всё гладко, но не в deb/dpkg.

Да куча всего. Куча файлов конфигураций, dh_make для сборки, shlibs, система зависимостей, отсутствие макросов, хранение исходников, как они подписываются, КАК ПАТЧИ НАКЛАДЫВАЮТСЯ. Про репозиторий можно еще можно сказать про тормозной apt-ftparchive, который при огромном количестве файлов и частой переиндексации просто умирает. Да и сам dpkg со своими разными параметрами для установленных и не установленных пакетов (в rpm нужно только исеользовать/неиспользовать ключ -p).

В RPM все настройки хранятся в одном spec.файле не нужно изучать эту страшную папку debian с конфигурациями.

Привлекательно там то, что из любого исходника можно за минимальное время получить deb-пакет. Своего рода checkinstall. И хоть какие-то системы для управления репозиторием. Например, простой и кривой mini-dinstall, который как раз и не дает сдохнуть окончательно apt-ftparchive.

Это всё проблемы дистроклепателей, я ещё раз повторю, что пользователю пакетов они никак жить не мешают. И к собственно deb/dpkg они напрямую отношения не имеют, это проблемы именно системы сборки, которую можно заменить, не меняя ничего в dpkg.

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

> Вот есть в Дебиане пакет sendmail, который suggests другой пакет - sendmail-doc. Как такое сделать в rpm?

В RPM тоже есть Suggests :-P

Я же вполне аргументированно сказал, а ты мне в ответ "а вот и нет" и "можно всегда". Если не хочешь спорить, зачем начинать? :)

Где ж ты раньше-то был! Правда что ли? А то тут весь спор идёт из предположения, что этого нет. :)

> Где ж ты раньше-то был!

Читал соседний тред :)

> Правда что ли?

4.3.3 -> 4.4: .... - define Suggests:/Enhances: and Priority: tag values.

> А то тут весь спор идёт из предположения, что этого нет. :)

Только поддержки их в менеджере пакетов мало - нужно, чтобы их 1) использовали 2) поддерживали в yum и прочих. Насколько я знаю, и с тем, и с другим - проблемы. Почему-то разработчикам Федоры такой тип зависимости не нравится :/

P.S. apt-rpm - отличная штука.

> Почему -i не может апгрейдить пакеты?

Для этого есть другие ключи -F и -U ...

блин... man rpm что-ли...

Ну, я просто неоднократно читал прямые утверждения, что единственный тип зависимостей, поддерживаемый rpm - это обычные жёсткие зависимости. Повсюду обман. :)

> неоднократно читал прямые утверждения, что единственный тип зависимостей, поддерживаемый rpm - это обычные жёсткие зависимости. Повсюду обман. :)

До относительно недавнего времени так и было. А пакетов с Suggests: я еще не встречал.

Дорогой мой, ты действительно считаешь, что трудности в сборки deb пакетов не имеют отношения к deb/dpkg?.. А вот то, что конечному пользователю, подойдет все что угодно здесь нельзя не согласиться.

Уж если говорить о конечном пользователе, то RPM если ему что-то не нравится вполне отчетливо скажет что, а dpkg выведет столбец информации, и даже иногда сделает вид что поставил. После чего можно будет видеть довольно хитрые Desired/Status в списке пакетов.

> Повсюду обман. :)

Ага, я тоже не знал =(

Кстати, раз зашел разговор об RPM, скажите pls в spec-ах есть флаги(вроде %define debug 0). Как их задавать через rpmbuild(не нагуглилось =( ).

> а dpkg выведет столбец информации

Я с Debian плохо знаком, но dpkg вроде не предназначен для вызова пользователем. apt-get ...

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

RPM ничего не светит и не светило никогда, потому что изначально поставлены были неправильные цели ;-) Кратко если, то нужно писать велосипед аналогичный dpkg/apt, вопрос только зачем?

>> В общем написать более-менее интелектуальный (и простой!) скрипт с >>использованием rpm задача та еще. А ведь это должно быть чуть ли не >>основным требованием к системной утилите, которой пользуются >>администраторы.

да-да. А еще я бы выкинул триггеры нафик - ибо зло и зависимости пакетов друг на друга. Provides тоже не нужны. Избавление от этих костылей заставит девелоперов сто раз подумать прежде чем делать через жопу.

>Я с Debian плохо знаком, но dpkg вроде не предназначен для вызова пользователем. apt-get ...

Угу, как и rpm, как и apt-get.

Да, если исходить из потребностей конечного пользователя и того, что он не может пускать dpkg/rpm/apt/yum, то ни DEB, ни RPM ему просто не нужны... А по хорошему, чтобы что-то узнать о пакете в системе RPM обладает более гибкими свойствами. А если ничем не пользоваться, то и разницы никакой нет. Какая разница между телефоном, допустим Nokia E61 и Siemens S35 если их использовать только для звонков? Никакой...

>> +1. Недавно переводил свой проект на RPM - ощутил сполна все >> описанные грабли.

ты еще не поддерживал несколько RPM дистрибутивов.

> Я с Debian плохо знаком, но dpkg вроде не предназначен для вызова пользователем. apt-get ...

Очень даже предназначен. dpkg - это аналог apt-get. Если у тебя есть одиночный deb-пакет, который нужно установить (например opera с официального сайта производителя), то ты говоришь dpkg --install opera*.deb

А apt-get - это уже следующий уровень, для работы с репозиториями. Он конечно чаще применяется, но и в прямом вызове dpkg ничего плохого нет.

>по хорошему, чтобы что-то узнать о пакете в системе RPM обладает более гибкими свойствами.

lol Учить мат. часть срочно!

s/аналог apt-get/аналог rpm/

>>Я с Debian плохо знаком, но dpkg вроде не предназначен для вызова пользователем. apt-get ...

>Угу, как и rpm, как и apt-get.

Что значит "угу"? И apt-get, и rpm предназначены для вызова _человеком_, будь он админ или хоумюзер, а dpkg - нет (AFAIK).

>> Я с Debian плохо знаком, но dpkg вроде не предназначен для вызова пользователем. apt-get ...

>Очень даже предназначен. dpkg - это аналог apt-get.

За что купил, за то и продаю. Я читал ругань в debian-devel, когда dpkg что-то там не так сделал - так вот багрепортеру сказали, что dpkg предназначен для вызова apt-get, а не человеком. Конечно, человек _может_ его вызвать, если захочет.

>dpkg - это аналог rpm

rpm и близко ни стоял с dpkg ;-]

> Кстати, раз зашел разговор об RPM, скажите pls в spec-ах есть флаги(вроде %define debug 0). Как их задавать через rpmbuild(не нагуглилось =( ).

Рулить через

--with/--without и --enable/--disable

> RPM ничего не светит и не светило никогда, потому что изначально поставлены были неправильные цели ;-) Кратко если, то нужно писать велосипед аналогичный dpkg/apt, вопрос только зачем?

Я балдею с вашего оптимизма. Только в стандарте поче-му то rpm.

Видать забыли с вами проконсультироваться.

>Я балдею с вашего оптимизма. Только в стандарте поче-му то rpm.

А rpm никогда и не делали _для удобства_, а только ради _стандарта_ ;-) Отсюда и все болезни его.

> lol Учить мат. часть срочно!

Ну тебе это тоже не помешает. Знаний rpm у тебя явно не хватает.

А по deb... Расскажи аналог --verify для dpkg. И как посмотреть url проекта с пом-ю dpkg. Я знаю что есть костыли чтоб это сделать. Но мы только про dpkg/rpm говорим.

И у dpkg и у rpm есть фичи которых нет у вророго.

> Рулить через

> --with/--without и --enable/--disable

Спасибо.

Прикрутить это к yum и вообще гента получится =)))

>Ну тебе это тоже не помешает. Знаний rpm у тебя явно не хватает.

Знаний у меня хватает, но если смотреть плюсы и минусы в общем по rpm/dpkg то выигрывает в итоге dpkg, к тому же никто не запрещает доработать dpkg ;-] А для rpm такие доработки можно считать лоботимией ;-)

>>Почему -i не может апгрейдить пакеты?

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

И как мы в debian-е ещё живы...

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

Если я правильно понимаю, в debian для этого есть система alternatives.

> выигрывает в итоге dpkg, к тому же никто не запрещает доработать dpkg

а rpm запрещают?

> А для rpm такие доработки можно считать лоботимией

Не знаю, очень легко делать rpm-пакеты, что src.rpm, что бинарники. А что вам в нём так мешает? Сидите в debian, ну и нечего поносить пользователей rpm-дистрибутивов.

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

> Если я правильно понимаю, в debian для этого есть система alternatives.

alternatives есть не только в Debian. Да и не для того оно. Не поможет ставить пакеты с одинаковым именем.

А вот Allow-Duplicated в dpkg нет.

> rpm и близко ни стоял с dpkg ;-]

Естественно. dpkg не умеет и половины того, чего умеет rpm.

> Кстати, раз зашел разговор об RPM, скажите pls в spec-ах есть

> флаги(вроде %define debug 0). Как их задавать через rpmbuild(не

> нагуглилось =( ).

В хоумдире юзера, из-под которого ведешь сборку пакетов, в файл .rpmmacros добавь:

%debug_package %{nil}

> не нагуглилось =(

http://fedora.redhat.com/docs/drafts/rpm-guide-en/

Правильно, yum, yast, rpmdrake и прочая появились от хорошей жизни и многих способностей rpm ...

То ли дело нам с apt и тузи.. ээ.. гентушникам с emerge хорошо живется

to Teak

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

А разве 'rpm -Uhv <...>.rpm' уже отменили