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

Дааа, я смотрю жизнь без portage и emerge так же тяжела как и несколько лет назад.
Юзал и .deb и .rpm в итоге понял, что несмотря на то что Gentoo source-based дистр и большинство пакетов надо-таки собирать, временя он в итоге экономит и личное и процессорное.

Всех благ.

Спасибо.

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

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

Разумеется они оба не умеют и четверти того что умеет emerge :)

> > Делается пакет <имя_почтовика>-palm-plugin, зависящий от <имя_почтовика> и от <тулзы_для_palm>.

> Ну просто наглядная демонстрация того, как делать не надо. Как я вообще должен догадаться о существовании этого второго пакета?

Точно также, как узнал о существовании первого.

> Приведу ещё один пример. Вот есть в Дебиане пакет sendmail, который suggests другой пакет - sendmail-doc. Как такое сделать в rpm? Либо вообще не прописывать никакой связи между пакетами, либо опять же городить какие-нибудь метапакеты типа sendmail-with-doc и sendmail-without-doc. :)

Еще не забудь "doc-without-sendmail".

Ето что же - ясли я захочу поставить пакет которому нужно 50 либ и каждая либа имеет еще пакет -dev и -doc, то я 100 раз должен давить кнопку "НЕТ"?

> Разумеется они оба не умеют и четверти того что умеет emerge :)

Ну-ка нука. emerge умеет проверять md5sum по всем установленным пакетам? Не ругаться при этом на изменения в конфигах? Отдельно писать про отсутствующие файлы?

emerge умеет бороться с проблемой вида "устанавливаемый пакет xxx требует фичи zzz, но использует ее не прямо, а требует пакета yyy, скомпиленного с поддержкой zzz"? Т.е. фактически зависимость от того, что пакет yyy компилился при наличии в системе zzz. И если у большинства пользователей yyy собирается без zzz, то эту проблему надо решать - установкой zzz, пересборкой yyy с ним и пересборкой всего, что потянула за собой пересборка yyy (к тому же, возможно, более новой, несовместимой версии...)

Где в моём посте утверждение, что что-то отменили? Что за мода отвечать на пост (вернее, его неверную интерпретацию) в отрыве от дискуссии?

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

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

Ключевое здесь "поче-му то"

Не ну если без фанатизма вы действительно считаете что rpm удобнее deb для конечного пользователя? Ведь большенство пользователей уходят на Debian- Ubuntu(как бы вы не топали ножками самый популярный дистр) в основном из-за apt... sinaptic... и почего *.deb

>Ведь большенство пользователей уходят на Debian- Ubuntu

Откуда такая "точная" информация?

>в основном из-за apt... sinaptic... и почего *.deb

Ну у меня "apt... sinaptic..." и прочего *.rpm :)

> Да, был бы у отцов-прародителей РедХэта моск - то был бы именно deb

Зачем усложнять банальности? Мсье любит извращения?

> urpmi В Мандриве ? с другими пакетными менеджерами для rpm работал только периодически, но с urpmi проблем не было.

Потому как сделано по уму. Я вот работал на yum - тихий ужас. Потому как Python и мозги индийские. :)

> Ведь большенство пользователей уходят на Debian- Ubuntu(как бы вы не топали ножками самый популярный дистр) в основном из-за apt... sinaptic... и почего *.deb

Из-за пакетного менеджера? Вы где такую траву берёте?! Воистину дебианщики - фанатики. :)

>>Ведь большенство пользователей уходят на Debian- Ubuntu

>Откуда такая "точная" информация?

В оригинале "большенство пользователей уходят на Debian- Ubuntu(как бы вы не топали ножками самый популярный дистр) в основном из-за apt... sinaptic... и почего *.deb" ubuntu debian forums + личный опыт

А что как то можете опровергнуть?

>Из-за пакетного менеджера? Вы где такую траву берёте?! Воистину дебианщики - фанатики. :)

Нет не из-за пакетного менеджера а из-за преимуществ которые он дает.

>Нет не из-за пакетного менеджера а из-за преимуществ которые он дает.

Точно даёт преимущества? именно этот пакетный менеджер? именно для пользователей?:) Назвать эти преимущества можете?

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

как ни странно, но все это есть:

-i -- только установить

-U -- обновить или установить

-F -- обновить только уже установленное

> Если уж заикнулись про 7-zip, то надо использовать не конеретно его, а архиватор с этим алгоритмом (lzma), но использующий тот же синтаксис,что и gzip.

если Вы заглянете на сайт 7zip.org, то прочитаете, что в сам 7zip использует несколько алгоритмов, не только lzma

> 3) Если с декомпресией все впорядке, то компресия сильно ресурсоемка и в стандартном варианте не паралелится.

странно, а на хоботе (и не только) им сравнивают двухядерные процессоры, а еще ранее он получал прибавку в скорости от HT :D

Для конечного пользователя абсолютно пофиг rpm или deb.

Нужно чтоб необходимый софт нормально работал.

Насчет самой популярной Убунты я совсем не уверен. Большинство конечных пользователей вообще считает что Linux и RedHat синонимы.

> если Вы заглянете на сайт 7zip.org, то прочитаете, что в сам 7zip использует несколько алгоритмов, не только lzma

Актуален-то только lzma.

Вообще, выиграть место можно без введения всяких несовместимостей в виде нового payload формата в rpm: там гарантированно поддерживаются bzip2 и gzip, а в федоре (и, думаю, много где) по умолчанию пакеты собираются с использованием gzip. Достаточно изменить конфиг - у всех работает, а места занимает меньше. bzip2 поддерживается еще с версии 3.0.какой-то

> как ни странно, но все это есть:

Как ни странно, ты не первый, кто написал мне это, не удосужившись поинетерсоваться, в каком контексте я это сказал. Чуть выше по треду я ещё одному уже отвечал, что я и не утверждаю, что чего-то нет. Речь шла совсем о другом.

>Для конечного пользователя абсолютно пофиг rpm или deb.

это конечно так? но для меня как пользователя такая простая вещь как "sudo apt-get install nvidia-glx " весьма приятная штука и проблем с зависимостями я встречаю на порядок меньше с .deb чем с .rpm та достало уже по инету шарить в поисках пакетов для Mandriva и ASP

ПО поводу популярности Ubuntu

Cмотрим http://distrowatch.com/ никто пока не доказал что их Шатлворт подкупил или убунтовцы счетчики накручивали, хотя конечно всё это не супер точно.

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

> многих способностей rpm ...

> То ли дело нам с apt

Правильно, atp-*, aptitude и прочая появились от хорошей жизни и многих способностей dpkg ...

P.S. :-)

С каких пор apt стал неотделим от dpkg?

Про yim, apt, aptitude разговора не было.

Про distrowatch хотел сразу написать но поленился. Про популярность среди пионеров я не говорил. Ясно что тут Ubuntu + Gentoo впереди планеты всей. Или вы всерьез думаете что серьезные люди ходят на distrowatch регистрироваться? Может еще и по конторам разнорядку рассылают - всем регистрироваться на distrowatch! :)

> Ну-ка нука. emerge умеет проверять md5sum по всем установленным

> пакетам?

Кстати да. Такой тривиальный случай. Побилась FS к примеру из-за глючного железа. Или любой другой глюк железа. Или кто-то подменил ps на хаченый и т.д. и т.п. Как, к примеру, проверить _ВСЕ_ установленные пакеты на корректность в гент00? В rpm можно задать поиск, он сверит _ВСЕ_ до единого файлы на FS, которые были установлены из rpm, проверит их MD5 и сверит со своей базой, подписанной PGP производителем, т.е. RedHat, SUSE, Mandrake. И если что-то не так, то он либо сообщит либо переставит _конкретный_ файл из авторизованной подписанной GPG базы пакетов. Как эту тривиальную задачу выполнить в гентооее?

> это конечно так? но для меня как пользователя такая простая вещь как

> "sudo apt-get install nvidia-glx " весьма приятная штука и проблем с

> зависимостями я встречаю на порядок меньше с .deb чем с .rpm та

[user@localhost ~]$ cat /etc/asplinux-release

ASPLinux release 11.2 (Ladoga)

[user@localhost ~]$ sudo yum install kmod-nvidia

Loading "installonlyn" plugin

Setting up Install Process

Setting up repositories

extras

[1/3]

asplinux-base

[2/3]

asplinux-updates

[3/3]

Reading repository metadata in from local files

Parsing package install arguments

Resolving Dependencies

Dependencies Resolved

=============================================================================

Package Arch Version Repository Size

=============================================================================

Installing:

kmod-nvidia i686 1.0.9631-1.2.6.18_1.2239.0.112asp asplinux-updates 1.6 M

Installing for dependencies:

kernel i686 2.6.18-1.2239.0.112asp asplinux-updates 16 M

xorg-x11-drv-nvidia i386 1.0.9631-1.112asp asplinux-updates 4.5 M

Transaction Summary

=============================================================================

Install 3 Package(s)

Update 0 Package(s)

Remove 0 Package(s)

Total download size: 22 M

Is this ok [y/N]: y

Ы?

> достало уже по инету шарить в поисках пакетов для Mandriva и ASP

Попробуй в следующий раз хоть немного изучить/почитать о том, куда лезешь. Доки, они рулез :-) Нафига всем напоказ выставлять свою безграмотность и лень - непонятно :-)

>это конечно так? но для меня как пользователя такая простая вещь как "sudo apt-get install nvidia-glx " весьма приятная штука и проблем с зависимостями я встречаю на порядок меньше с .deb чем с .rpm та достало уже по инету шарить в поисках пакетов для Mandriva и ASP

Это конечно так, но для меня как пользователя rpm-based системы такая простая вещь, как "sudo apt-get install nvidia-glx" весьма приятная штука и проблем с зависимостями я в дистрибутиве или репозитарии я не встречаю. О чём вы вобще рассказываете? О rpm или о "Mandriva и ASP"?:)

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

да и с другой стороны что если на моей домашней тачке не ультра-мега-энтерпрайз чего нибудь я что уже не пользователь линукса тем более что его сейчас вовсю на десктоп продвигают? Из тысяч таких пионеров сейчс и складывается ваш любимый продакшн энтерпрайз в будущем. Юникс и попал в своё время в одно место из-за подобных вашей позиции.

>да и с другой стороны что если на моей домашней тачке не ультра-мега-энтерпрайз

У меня тоже:)

>я что уже не пользователь линукса

Пользователь... но ламер в споре deb/rpm, о чём вам и намекнули? Реклама "Иногда лучше жевать, чем говорить" - для вас:)

>Из тысяч таких пионеров сейчс и складывается ваш любимый продакшн энтерпрайз в будущем.

Нет, "продакшн энтерпрайз в будущем" складывается из "пионеров", которые читают, а не рассуждают о вещах, в которых, мягко говоря, "плавают":)

>Юникс и попал в своё время в одно место из-за подобных вашей позиции.

Ещё один бред...:) Нельзя же так лажаться на каждом утверждении:)

Да просто есть люди которые работают, а есть те которые на distrowatch регистрируются. И это совсем разные люди.

На домашней тачке держи хоть LFS. Как пойдешь на работу - про него забудешь.

>Попробуй в следующий раз хоть немного изучить/почитать о том, куда лезешь. Доки, они рулез :-) Нафига всем напоказ выставлять свою безграмотность и лень - непонятно :-)

Тебе не кажется что если я работаю в Linux не 1-ый год я всё таки не совсем безграмотен.

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

> Пользователь... но ламер в споре deb/rpm, о чём вам и намекнули? Реклама "Иногда лучше жевать, чем говорить" - для вас:)

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

Единственное что я сказал что для меня такого вот пионера- домашнего- смол офис пользователя, использование Debian Ubuntu с .deb гораздо приятнее чем .rpm дистрибутивов и что многие выбирают Debian Ubuntu только из-за удобства работы с пакетами и из-за этого я ушел с ASP 9 Mand 10. Я не знаю недостатки ли &#1108;то RPM или программы для работы с ним реализованы криво или ещё что. Я просто высказал своё мнение.

> если Вы заглянете на сайт 7zip.org, то прочитаете, что в сам 7zip использует несколько алгоритмов, не только lzma

Пользуюсь 7z уже года 2. Всё что ниже - моё личное мнение, никому его не навязываю :) Там 4 алгоритма: Deflate (совместимый с zip и gzip, но на пару процентов лучше сжимает), bzip, LZMA (хорош для файлов, сжимаеиых раза в 2-3, например, бинарных программ, но жрёт много памяти при сжатии - в 10-12 раз больше словаря, если использовать своп, сжатие затягивается на порядки) и ppmd (хорош для файлов, сжимаемых раз в 10, например BMP, но жутко тормозной). И lzma, и ppmd сжимают на уровне RAR, т.е. заметно лучше, чем gzip и bzip (думаю, во многом за счёт большего словаря). На малых архивах (1-2 мегабайта) выигрыш невелик, на больших (~50 мегабайт) становится заметна низкая скорость (особенно ppmd). ИМХО, замена tar.gz на tar.ppmd обернётся жуткими тормозами (ppmd давно существует в виде отдельной программы, но из-за низкой скорости прменяется редко, автор сам пишет, что архиватор способен заменить gzip/bzip, но неудобен для распаковки tarов налету). tar.lzma может и прокатит.

Вообще 7z всё ещё развивается (причём именно lzma). У меня был случай, когда новый 7za (4.чтототам) не опознал старый архив (3.чтотоещё) :( Да и восстановление битых архивов просто отсутствует (но имхо для *.tar.* оно бесполезно).

>tar.lzma может и прокатит.

AFAIK LZMA хорош на т.н. solid-архивах (это когда набор файлов перед сжатием переупорядичавается по типу), так что на единичном файле (будь-то tar или cpio) ефект значительно снизится.

>Да и восстановление битых архивов просто отсутствует (но имхо для *.tar.* оно бесполезно).

AFAIR автор обещал в будущем добавить эту фичу. До 4.x и "многотомных архивов" в нём не было, автор обещал это в ветке 4.x - сделал:)

Был я фонатом RPM где-то до первой fedora. Попробовал Debian чисто из интереса, с тех пор больше к RPM не притрагиваюсь. Все проще, логичней, и в повседневной работе на порядок продуманней. yum в сравнение с aptitude и работает глючно и ресурсы жрет.

> AFAIK LZMA хорош на т.н. solid-архивах (это когда набор файлов перед сжатием переупорядичавается по типу), так что на единичном файле (будь-то tar или cpio) ефект значительно снизится.

Solid - это когда все файлы воспринимаются архиватором как единое целое. То есть *.tar.gz - тоже solid. Если для сортировки по типу и есть специальное название, я его не слышал ни разу. Сортировка по типу, действительно, полезна, но, имхо, если словарь достаточно большой - разницы не будет (другой вопрос, осилит ли машина такой размер словаря :) ). Имхо, проблема zip/gzip и bzip в том, что у них размер словаря фиксирован, и для современных нужд маловат.

Покопался и нашёл http://tukaani.org/ - кто-то уже вовсю переводит Слаку на lzma. Так глядишь, и rpm с deb форкнут :)

Чёрт, прозевал, уже выше ссылка на него была.

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

Посмотри топ дистрибутивов на ЛОР, увидишь, что большинство уходит на Генту, ламо.

> А вот позволять ставить пакеты разных версий с одинаковыми названиями - сомнительная идея (даже если по файлам они не пересекаются). Это только путаницу создаст, и для apt/yum, да и для тебя самого.

При всей потенциальной опасности процедуры, она бывает полезна при частичных апгрейдах. То есть, например, часть системы уже переехала на новую либу, а часть - еще нет, и качать гигабайты ради того, что мэнтейнер обновил .so'шку нет никакого желания. Да, я понимаю, дебьяновцы для решения подобных проблем лепят в имена пакетов библиотек мэйджоры в обязательном порядке, но это как если бы я ко всем окружающим людям мог бы обращаться только по полному ФИО :-)

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

Пользователей волнуют проблемы качества сборки пакетов и качество дистро-специфичной обвязки. По моим наблюдениям, "в среднем по больнице" качество пакетов в Сардже (полнота и аккуратность сборки, "фичастость" итп) ниже, чем у rpm'ных мейджоров. Хотя да, Убунту 6.10 вполне себе приятная глазу вещь, так что, здесь не в пакетном менеджере дело.

Ну, и еще, конечно, напрягает отсутствие/неиспользование виртуальных зависимостей вида perl(CGI) (вариант: perl(CGI.pm)). Подчас приходится думать, что поставить.

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

Только медленно индексы читает в сравнении с apt/dpkg. Но таки да, у нас и система зависимостей ... побольше будет :-)

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

(Пожимая плечами) есть. В спеке -

%define debug 0

снаружи, при сборке

rpmbuild --define 'debug 0' ...

В альте еще стандартно определяются чуть более удобные "надстроечные" макросы вида

%def_with feature
или
%def_without feature

с возможностью переопределить заданный таким образом дефолт из командной строки или rc-файла (по сути, аналог гентушного USE).

В спеке затем можно использовать

%if_with feature
или
прямой подстановкой в аргументы ./configure:

%{subst_with feature}.

Аналогично для enable.

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

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

У наших продуктов в списке поддерживаемых с десяток rpm-based дистрибутивов и их версий (а с учетом различных платформ - и того больше), два deb-based, и еще кой-чего на десерт ;-)

> Дааа, я смотрю жизнь без portage и emerge так же тяжела как и несколько лет назад. Юзал и .deb и .rpm в итоге понял, что несмотря на то что Gentoo source-based дистр и большинство пакетов надо-таки собирать, временя он в итоге экономит и личное и процессорное.

Сложно сказать... Время экономит не деб/рпм/емердж, а человек, который писал рулесы/спеки/портежи, искал и подтачивал разные полезные патчи и так далее. И по этому параметру генту мне не нравится, хотя я с уважением отношусь к [некоторым] людям, которые его используют, и сам частенько дергаю оттуда некоторые патчи, благо,они есть под руками.

> В rpm можно задать поиск, он сверит _ВСЕ_ до единого файлы на FS, которые были установлены из rpm, проверит их MD5 и сверит со своей базой, подписанной PGP производителем, т.е. RedHat, SUSE, Mandrake.

Это если злобные хаксоры не подменили считалку md5 итп. К сожалению, примеры имеются.

RPM ужасен, и зачем на него время тратить и силы? Есть же добрый мощщный DEB. Его уже и солярщики признали кое какие =))

Отвечу на накопившиеся реплики...

По поводу -i и апргрейда пакетов. Есть явная асимметричность между rpm и yum и это проблема: в rpm можно поставить пакет с помощью -U, а в yum только с помощью install. В итоге, если вам надо написать скрипт, который скажем гарантированно устанавливает необходимый пакет на систему (даже с помощью yum), то придется сначала а) проверить стоит ли такой пакет уже в системе с помощью rpm -q б) если не стоит, позвать yum install Если в этот скрипт потребуется добавить управление версиями (нужно поставить пакет не ниже такой-то версии), то добавится еще несколько шагов.

По поводу пакетов с одним именем. Это полный бред, повторю еще раз. От этого одно зло. В debian sarge поставляется одновременно и apache 1.3 и apache 2.0. Первый пакет называется apache, второй apache2 - все апгрейды автоматически будут работать в одной ветке, так что apt-get dist-upgrade никогда не сменит major-версию продукта.

Моя критика на rpm/yum была именно как на низкоуровневую (базовую и важную) утилиту в системе, которая должна обеспечивать предсказуемое и разумное поведение, в том числе по стандартам UNIX. Исправить все эти ошибки можно и даже, скорее всего, очень просто, но представьте сколько уже написано скриптов и проектов, в которых учитываются все эти грабли, сколько гемора уже накопилось. Например как у меня, где мне просто _приходится_ разбирать стандартный вывод yum для того чтобы понять, что произошла ошибка!

> RPM ужасен, и зачем на него время тратить и силы? Есть же добрый мощщный DEB. Его уже и солярщики признали кое какие =))

Я достаточно ясно выразился? У нас в списке поддерживаемых платформ десяток rpm-based дистрибутивов. Нам за это деньги платят, достаточные, чтобы сидеть и разбираться с каждой из возможных систем дистрибуции.

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

Да блин!

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

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

Я лично не собираюсь уходить с debian в именно благодаря apt. Но я не считаю, что все остальное must die. Для линукс моногамия идей - это смерть. Можно, оставаясь приверженцем какого-то продукта, бороться за его качество. И это большинству пользователей под силам, если они будут делать баг-репорты.

> По поводу -i и апргрейда пакетов. Есть явная асимметричность между rpm и yum и это проблема: в rpm можно поставить пакет с помощью -U, а в yum только с помощью install.

А вы не пользуйтесь yum'ом, пользуйтесь аптом или еще чем. При чем тут недостатки rpm'а??

> По поводу пакетов с одним именем. Это полный бред, повторю еще раз. От этого одно зло. В debian sarge поставляется одновременно и apache 1.3 и apache 2.0. Первый пакет называется apache, второй apache2 - все апгрейды автоматически будут работать в одной ветке, так что apt-get dist-upgrade никогда не сменит major-версию продукта.

Еще раз специально повторяю, медленнее... Да, установка двух пакетов разных версий - ситуация нештатная. Но иногда это требуется. Пример - когда библиотека меняет soname, а вытягивать обновления для всех пакетов, от неё зависящих _лично_ _мне_ и _прямо_ _сейчас_ по каким-то причинам лениво. Мэнтэйнер пакета не всегда в состоянии предугадать ситуацию, и дебиановское полиси относительно именования библиотек тут тоже не всегда помогает.Возможности rpm'а позволяют мне обойтись без тотального апдейта или самостоятельной пересборки, а возможности deb'а - нет.

> А вы не пользуйтесь yum'ом, пользуйтесь аптом или еще чем. При чем тут недостатки rpm'а??

Как разработчик я не могу всегда пользоваться тем что хочу - есть требования.

> Да, установка двух пакетов разных версий - ситуация нештатная... Пример - когда библиотека меняет soname...

Библиотека не случайно меняет soname. Чаще всего разные мажор версии библиотек несовместимы бинарно _и_ несовместимы по интерфейсам. Просто пересборка приложений с новой версией библиотеки не поможет. Еще вариант stable и devel версии пакетов -- например ruby1.8 и ruby1.9. Т.е. это ситуация не нештатная, а обычная. Если разные версии одного проекта - могут быть установлены и развренуты как независимые пакеты - то это должно быть возможно сделать. А зачем это надо должны решать пользователи. Ограничивать пользователя в том, что не представляет технической трудности - глупо. В этом смысле debian policy следует принципу KISS.