LINUX.ORG.RU
ФорумAdmin

Ненавижу RPM и RPM-based дистрибутивы


0

0

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

Вот обновлял я в последние день-два один сервер удалённо по ssh с ASPLinux 7 до ASPLinux 12. Задача весьма нестандартная и по-хорошему надо переставлять всё заново, но очень уж лениво ехать его из стойки с хостинга выковыривать и так далее. Впринципе ничего невозможного в этом не оказалось, но вот только несколько раз пришлось руками исправлять кучу зависимостей, в которых yum не мог разобраться. И самое главное успешно исправлять, так что это очевидно недоработки yum'а.


ну может трахаться с какой-нибудь слакварью, кто мешает-то

и кстати, из RPM-based дистрибутива тоже можно сделать помойку "make install"-стайл

anonymous
()

>Мало того, что они всегда в зависимостях за собой тянут кучу всякого барахла,

Разве лучше когда все это и еще немного другого баразха уже включено в пакет?

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


А у всех с постоянным...

>Вот обновлял я в последние день-два один сервер удалённо по ssh с ASPLinux 7 до ASPLinux 12.


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

iRunix ★★★★
()

> Вот обновлял я в последние день-два один сервер удалённо по ssh с ASPLinux 7 до ASPLinux 12

А это ничего, что за это время сменилось два поколения glibc (glibc-2.3, glibc-2.4), нитиевая модель, два поколения компиляторов (gcc3, gcc4), версии mysql, php, bind, posgres прыгнули в мажорной цифре, куча софта стала unsupported или obsolette, sendmail и также жестоко изменились...

no-dashi ★★★★★
()

Ну и нафига этот бред в admin-форум пихать? Рассуждения об обиженности жизнью в толксы!

sidor ★★
()

>Мало того, что они всегда в зависимостях за собой тянут кучу всякого барахла

"А ваша Галя балувана." На днях попытался снести "Local Printer Support " в tru64. Обнаружилось, что от него зависит какой-то "аппаратный" security патч. Т.ч. не всё так уж плохо. Тут хоть исправив пару строк в spec-ах легко получить "независимый" пакет.

DonkeyHot ★★★★★
()

>Вот обновлял я в последние день-два один сервер удалённо по ssh с ASPLinux 7 до ASPLinux 12

95ую до Висты обновлять не пробовал?

redgremlin ★★★★★
()

> Вот обновлял я в последние день-два один сервер удалённо по ssh с ASPLinux 7 до ASPLinux 12.

Вообще-то подвиг совершил (без подколок). Респект. Остальные обидки на RPM - субъективно.

Это даже круче, чем Fedora3 до Fedora9 обновить... сменились версии ядра (2.4.* -> 2.6.*), сменились библиотеки, технологии... И то, что ты смог обновить с 7 до 12 АСПа говорит о твоём неслабом скилле.

Преамбула закончилась.

Теперь по существу: имея такой внушительный экспириенс, ты тут плачешься на RPM? Самому не смешно? :)

P.S. Да, у rpm(+yum) есть недостатки, но не смертельные. PackageKit во многом призван исправить их.

Slavaz ★★★★★
()

По поводу 7 и 12 не скажу, но разбирался с ASPLinux 9.2, там как раз не хватало зависимостей, пакет ставишь, он ставится, но не работает (ему чего то не хватает). Сразу же вспонилась Slackware 3.0, которую я таскал домой на дискетах.

Вам респект, но нафига в обновлялись опять до ASP? Обновили бы ASPLinux до Debian...

mky ★★★★★
()
Ответ на: комментарий от no-dashi

>А это ничего, что за это время сменилось два поколения glibc (glibc-2.3, glibc-2.4), нитиевая модель,...

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

roller ★★★
()
Ответ на: комментарий от mky

>Обновили бы ASPLinux до Debian...

Юм не позволит )

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

roller ★★★
()
Ответ на: комментарий от roller

> А вообще тулза позволяющая перейти ит дистра к дистру весьма была бы востребованна.

Тулза, позволяющая корректно проапгрейдить RH-based дистр на более высокую версию есть: http://forum.redhat-club.org/viewtopic.php?id=6356

Но, вероятно, если большая дистанция между версиями, то только ручное обновление.

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


Если версии пакетов уж очень разнятся, то могут поменяться как назначения параметров в конфигах, так и местоположение самих этих конфигов.
"Преобразовать конфиги" - это нужно иметь правила преобразования между каждой версией rpm-пакета (где поменялось назначение параметров); и так для всех пакетов.
"Раскидать по нужным папкам" - уже попроще, но всё же всё та же таблица "пакет - версия".
"Базы данных" - простейший пример: PostgreSQL. Без pg_dumpall(|bzip2) между версиями никак. Хорошо, если есть место, куда дамп скидывать...

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



Slavaz ★★★★★
()
Ответ на: комментарий от roller

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

Мы живем в очень неидеальном мире...:)

sidor ★★
()

> Разве лучше когда все это и еще немного другого баразха уже включено в пакет?

лучше, когда как в дебиане, зависимости разделены на requires, recommends и тд.

> А это ничего, что за это время сменилось два поколения glibc (glibc-2.3, glibc-2.4), нитиевая модель...

да в том и дело, что принципиальных проблем с этим ни с чем не было. я спешил и особо не вникал, но, например с glibc дело было так - yum update вываливает кучу конфликтов, пишу руками yum update glibc-common, потом проходит yum update. а, еще

главная проблема была в обновлением питона. это вообще очень непроработанное место - куче пакетов, в том числе и самому yum нужна именно старая версия питона, поэтому его нельзя обновить, а пакеты нельзя обновить, потому что им (новым) нужен новый питон, который нельзя поставить, потому что... и так далее. тут уже приходилось rpm -i --nodeps новый питон, после чего не работал yum, который тоже руками через rpm ставить.

с ядром та же хрень - новому нужен новый module-init-tools, их нельзя поставить, потому что они конфликтуют со старым modutils, а их нельзя удалить, потому что они нужны старому ядру. ну опять же это yum не может, руками без проблем.

> Вообще-то подвиг совершил (без подколок). Респект. Остальные обидки на RPM - субъективно.

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

> По поводу 7 и 12 не скажу, но разбирался с ASPLinux 9.2, ...

в 9.2 вообще ошибку нашел, там rpm-python импортит функцию, которой вообще нет. в 9.1 и 10 не импортит. опять все упало и правилось руками.

pronvit
() автор топика
Ответ на: комментарий от Slavaz

Он таки съездил и переставил все с нуля, просто не признается :)

emaxx ★★
()
Ответ на: комментарий от pronvit

> Например с glibc дело было так - yum update вываливает кучу конфликтов, пишу руками yum update glibc-common, потом проходит yum update. а, еще

> главная проблема была в обновлением питона.

Это очень печально, но причем тут RPM вообще? Проблема с yum - возможно, криво собранный пакет с Python - вероятно, а RPM причем? Есть претензии к формату пакетов? Зависимости отслеживаются некорректно? Верификация не работает? В чем проблема с RPM, еще раз?

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

> Это очень печально, но причем тут RPM вообще?

может, я и не прав, но отсутствие на моей памяти проблем с дебиан-based дистрибутивами и какие-то частые, опять же, на моей памяти косяки с rpm навели меня на мысль, что это какая-то родовая проблема rpm, все-таки у нее и у deb механизм описания зависимостей разный.

pronvit
() автор топика
Ответ на: комментарий от gnomino

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

pronvit
() автор топика
Ответ на: комментарий от pronvit

или удали, смотря что там надо. можно хоть вообще все относящееся к ядру снести да заново забив на зависимости dpkg восстановить

pronvit
() автор топика
Ответ на: комментарий от pronvit

>ну посмотри на что ругается apt-get, забей на него и руками с помощью dpkg попробуй исправить

Да уже все это было сделано, вопрос -- как удалить из базы пакетов "битые"?

gnomino
()
Ответ на: комментарий от pronvit

Ну, то что доктор прописал, спасибо! Таки RPM рулит.

gnomino
()

На самом деле deb-based, в случае неумелого использования, ничуть не лучше rpm-based дистрибьютивов.. Впрочем, как и все остальные, в том числе и сорсебейзд.. Всё зависит от качества профита и так далее..

MiracleMan ★★★★★
()
Ответ на: комментарий от pronvit

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

Хочешь я сейчас все то же самое переведу на термины rpm-based дистрибутивов? И ты поймешь, что рпм и деб - это одни и те же яйца, только в разных ракурсах... :))))))))

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

:)))))))) Вывод - все твои восклицания по поводу rpm - не более, чем неумение готовить :)

sidor ★★
()
Ответ на: комментарий от sidor

Ну а ежели серьезно... Описанные топикстартером проблемы естественны. Во-первых - скачек шибко сильный. Аж через несколько версий. ASP - fedora-based дистрибутив. В федоре от версии к версии делаются кардинальные изменения. Какой-то софт выкидывается. Какой-то добавляется. Меняются наименования пакетов, их компоновка. И вшивать все это в yum, чтоб он смог разрулить все, что наменялось за эти годы - практически нереально. Да и смысла нет. Ежели хочешь извращений - доставай бубен :) А как жеж иначе?

sidor ★★
()
Ответ на: комментарий от sidor

> :)))))))) Вывод - все твои восклицания по поводу rpm - не более, чем неумение готовить :)

вы не по теме. мои восклицания были по поводу неспособности yum разрулить зависимости на полностью здоровой системе. а про удаление руками был ответ человеку, который /lib/modules стёр

> Во-первых - скачек шибко сильный.

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

pronvit
() автор топика
Ответ на: комментарий от pronvit

ну во-первых ты не писал, что по версиям шел. во-вторых - насколько я помню, федора и ее клоны никогда и не заявляли, что можно на лету апгрейдить дистр (если не прав - ткните ссылкой на офсайт аспа или федоры об этом). У них механизм через инсталлятор... Бутишься с диска, он находит старый дистр и предлагает апдейтиться. И именно потому, что и изменения бывают зачастую кардинальные, и дистры очень часто выходят (раз в пол года)... Если ты выбрал нестандартный способ - ну шо ж... ССЗБ... Что ж тут возмущаться?

sidor ★★
()

Подписываюсь, дома и на работе уже года три слакваре использую, тут недавно товарищь попросил посмотреть мандриву 2008.1 и что то там доустановить, установка пакетов превращается в какое то мучение, ну зачем так мелко дробить пакеты?

splinter ★★★★★
()
Ответ на: комментарий от splinter

>установка пакетов превращается в какое то мучение

man urpmi

redgremlin ★★★★★
()
Ответ на: комментарий от splinter

Я седел на Slackware 12 потом обновился до MOPS 6.1 простой установкой мопса поверх слаки не трогая разделы, так все заработало сразу и вобще ничего руками доделывать не прищлось, даже удивился. Слака рулез!!!

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