LINUX.ORG.RU

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


0

0

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

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



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

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

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

Всех благ.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

P.S. :-)

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

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

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

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

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

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

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

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

> пакетам?

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

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

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

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

> "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

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

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

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

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

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

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

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

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

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

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

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

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

У меня тоже:)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: Перспективы 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.* оно бесполезно).

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

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

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

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

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

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

Led ★★★☆☆ ()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> Кстати, раз зашел разговор об 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

По поводу -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 для того чтобы понять, что произошла ошибка!

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

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

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

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

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

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

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

Да блин!

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

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

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

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

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

> По поводу -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'а - нет.

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

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

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

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

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

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

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