LINUX.ORG.RU

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


0

0

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

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



Проверено: Teak ()

Ответ на: Re: Перспективы RPM от anonymous

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

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

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

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

bada ()
Ответ на: Re: Перспективы RPM от anonymous

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

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

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

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

Teak ★★★★★ ()
Ответ на: Re: Перспективы RPM от Tigro

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

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

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

Teak ★★★★★ ()
Ответ на: Re: Перспективы RPM от Teak

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

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

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

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

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

MrKooll ★★★ ()
Ответ на: Re: Перспективы RPM от MrKooll

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

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

Zloy_Krys ()
Ответ на: Re: Перспективы RPM от MrKooll

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

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

Teak ★★★★★ ()
Ответ на: Re: Перспективы RPM от Tigro

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

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

Hokum ☆☆☆☆ ()
Ответ на: Re: Перспективы RPM от Teak

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

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

Teak ★★★★★ ()
Ответ на: Re: Перспективы RPM от MrKooll

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

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

Zulu ★★☆☆ ()
Ответ на: Re: Перспективы RPM от Zloy_Krys

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

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

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

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

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

MrKooll ★★★ ()
Ответ на: Re: Перспективы RPM от Zulu

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

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

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

MrKooll ★★★ ()
Ответ на: Re: Перспективы RPM от Teak

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

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

MrKooll ★★★ ()
Ответ на: Re: Перспективы RPM от MrKooll

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

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

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

Teak ★★★★★ ()
Ответ на: Re: Перспективы RPM от Teak

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

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

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

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

Tigro ★★ ()
Ответ на: Re: Перспективы RPM от Tigro

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

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

Teak ★★★★★ ()
Ответ на: Re: Перспективы RPM от Teak

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

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

Tigro ★★ ()
Ответ на: Re: Перспективы RPM от Teak

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

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

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

tailgunner ★★★★★ ()
Ответ на: Re: Перспективы RPM от Tigro

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

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

Teak ★★★★★ ()
Ответ на: Re: Перспективы RPM от tailgunner

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

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

Teak ★★★★★ ()
Ответ на: Re: Перспективы RPM от Teak

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

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

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

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

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: Re: Перспективы RPM от bada

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

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

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

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

frost_ii ★★★★★ ()
Ответ на: Re: Перспективы RPM от tailgunner

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

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

Teak ★★★★★ ()
Ответ на: Re: Перспективы RPM от Teak

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

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

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

tailgunner ★★★★★ ()
Ответ на: Re: Перспективы RPM от Teak

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

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

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

Tigro ★★ ()
Ответ на: Re: Перспективы RPM от Teak

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

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

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

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

YesSSS ★★★ ()
Ответ на: Re: Перспективы RPM от Tigro

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

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

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

tailgunner ★★★★★ ()

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

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

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

Metallic ()
Ответ на: Re: Перспективы RPM от bada

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

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

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

anonymous ()
Ответ на: Re: Перспективы RPM от tailgunner

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

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

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

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

Tigro ★★ ()
Ответ на: Re: Перспективы RPM от klon

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

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

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

anonymous ()
Ответ на: Re: Перспективы RPM от tailgunner

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

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

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

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

Teak ★★★★★ ()
Ответ на: Re: Перспективы RPM от Tigro

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

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

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

Metallic ()
Ответ на: Re: Перспективы RPM от Tigro

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: Re: Перспективы RPM от Teak

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: Re: Перспективы RPM от YesSSS

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

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

Рулить через

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

MrKooll ★★★ ()
Ответ на: Re: Перспективы RPM от Metallic

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

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

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

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

MrKooll ★★★ ()
Ответ на: Re: Перспективы RPM от MrKooll

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

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

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

Metallic ()
Ответ на: Re: Перспективы RPM от Metallic

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

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

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

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

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

MrKooll ★★★ ()
Ответ на: Re: Перспективы RPM от MrKooll

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

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

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

Спасибо.

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

YesSSS ★★★ ()
Ответ на: Re: Перспективы RPM от MrKooll

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

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

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

Metallic ()
Ответ на: Re: Перспективы RPM от anonymous

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

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

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

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

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

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

Xellos ★★★★★ ()
Ответ на: Re: Перспективы RPM от Metallic

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

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

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

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

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

los_nikos ★★★★★ ()
Ответ на: Re: Перспективы RPM от Xellos

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

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

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

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

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

MrKooll ★★★ ()
Ответ на: Re: Перспективы RPM от Metallic

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

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

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

dmesg ()
Ответ на: Re: Перспективы RPM от YesSSS

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

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

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

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

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

%debug_package %{nil}

dmesg ()
Ответ на: Re: Перспективы RPM от dmesg

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

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

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

zodiac ★★ ()
Ответ на: Re: Перспективы RPM от Teak

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

to Teak

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

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

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