Гм. Сейчас прочитаем. Единственный вопрос к автору - неужели он думает, что никто не знает, в чем недостаток rpm?

Как дети просто.

>Как дети просто.

а это они и есть... Даёшь новое поколение линуксоидов... Каждому Туксу по Лоло !!! (если кто этот мультик моего детства помнит) ..

>From experience, you know that none of the RPMs built for other distributions will work on your system. In fact, if it isn't built specifically for the version of the distribution you have installed, it ain't gonna work.

Ламерам в этом мире очень тяжело жить. Вот и у человека пакет от другого дистрибутива не работает. Я так думаю, что он его тащил с другой архитектуры, или от чего-то совсем древнего, а про команду --nodeps он не знал.

>You manage to find the exact RPM you need. You try to install it, and discover that you have to either install some other software, or upgrade some part of your system.

Что неудивительно. В данном случае виндовый принцип "все свое ношу с собой" для пользователя удобнее, но превращает систему в помойку. Про apt, который есть и для mdk, автор тоже не слышал.

>RPM specs are complicated and are difficult to build correctly. As a consequence, almost nobody does build them correctly. The most commonly used switch god Linux admins use is "--badreloc".

Ну если ничего перед этим не прочитать, то да. А вообще помню бессонную ночь с installshield - тоже хорошего мало.

>has a low-grain dependency version mechanism. An RPM spec builder can't, for instance, say that package A requires some version of package B, where the version is greater that 2.0 but less than 3.0, and not version 2.3.

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

>RPM makes it hard to install multiple versions of the same package on a system. This isn't the sole fault of RPM; the LSB -- the legacy left to Linux by Unix contributes much to this. Since two versions of the same package tend to install the same files in the same place, conflicts are common.

Интересно, а зачем? Вообще, насколько я помню, путь установки можно менять. Хотя зачем мне, например, kde 3.1 и kde 3.2 одновременно, я не понимаю.

>Finally, RPM is stupid. If a dependency isn't in the database, it doesn't exist. For example, if I have library X version Y installed, RPM will insist that it isn't installed merely because it isn't in the database. I'm sorry, but this is just retarded. It would be trivial to check ldconfig and see if the library exists.

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

>slowly degrading as various pieces of the system fall out of RPM sync,

Ну тут помогут 3rd party tools, о которых он упоминал выше - yum, up2date, apt.

>Self-contained software, a-la NeXTSTEP and MacOS-X. NeXTSTEP, and OS-X via inheritance, tends to package software in .apps. These are directories that contain a mini-Unix file system.

Винды по юниксовски - program files, $PATH длиной в Млечный путь... Хорошая перспектива, славная...

Как я понимаю, он только что "решил проблему" установки трех kde на одну машину ;) А вот как же с зависимостями?

>behind even Redhat, the slowest of RPM distributions

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

P.S. Очень порадовала забота о неадминах, в свете gentoo - с таким же успехом можно его научить пользоваться rpm (потому что его теперешние навыки просто ужасны).

P.P.S. Он таки знает про --nodeps ;)

> Self-contained software, a-la NeXTSTEP and MacOS-X. NeXTSTEP, and OS-X via inheritance, tends to package software in .apps. These are directories that contain a mini-Unix file system.

Это вообще бред сказочный. А как же с библиотеками шаренными - или их просто не должно быть, все линкуем статикой? Или создавать 1е6 подкаталогов в /usr/lib и на ходу переключать LD_LIBRARY_PATH (опять же, как указано выше, сделав его длиной с млечный путь). При этом автор советует отслеживать зависимости через ldconfig - что при подобных играх с библиотеками вообще практически лишено смысла.

Ощущение, что автор наскоро пережевал все, что прочел плохого про rpm (твердо решив не упоминать про apt-rpm) - а потом придумал за 2 минуты НЕЧТО, что должно спасти мир от всех этих несчастий.

Да, а про версии - могу дать еще один пример, когда версию нужно знать "в диапазоне значений". Mozillа несовместимо меняет свои API с каждым релизом (мало того, что плюсовый так еще и нестабильный как ...). Посмотрите на код галеона - порадуйтесь.

про идею NeXTSTEP, Program files и пр. ...

вспомним BeOS ... у каждой проги своя папка в /boot/beos/apps/, НО со всех нужных бинарников символьные ссылки в /boot/beos/bin, который в $PATH !!!

если руки растут откуда надо - можно делать всё... (к автору статьи не относится ...)

... да, действительно новости из пальца высасываются, это кем надо быть чтобы здесь, в колыбели росийского Linux'а, учить людей ламерскими постами (слово что-ли знакомое увидел - RPM) ...

> Well, that, and the fact that Debian packages usually lag several months behind even Redhat, the slowest of RPM distributions. By the time you get something on Debian, everybody else has already upgraded to the next version.

Просто тестируется дистр не на пользователях, в отличие от RH и прочего [sensored]. А для дюже продвинутых есть testing и unstable.

Ну дык сейчас воткни rh 7.3 или 9 - вот тебе и stable по меркам debian, fc 1 - testing, а ее тесты - unstable ;)

> в колыбели росийского Linux'а, учить людей ламерскими постами
Оно и видно что колыбель =) Ну или ясли накрайняк.

Я уж небуду спорить с теми кто невнимательно
читал статью Ok?

Автор весьма правильно и коротко сформулировал
основные проблемы RMP.

1)Ненужные зависимости которые задолбаешся удовлетворять.
--nodeps это все таки ненормальный режим работы
тогда уж rpm не особо нужен и tar.gz сгодится.

2)Нелзя без tirdparty средств выяснить чего
нехватает - зависимости только на один
уровень вглубь.

3)Нельзя корректно поставить несколько
версий одного пакета. Это действительно нужно
бывает, _особенно_ в Linux. Поломают
что нибудь нужное в новыой QT
так, что очень нужная прога с ней не работает.
А со старой KDE новый не запускается.

4)Нельзя ставить программы от пользователя
в его домашний каталог. Нет то-есть если
потрахаться то конечно все можно. Но простых
способов это сдеть с RPM нет.

5)Не видит то что поставлено мимо RPM. Из tar.gz
например. Чего орать что libXm нет если я Lesstif
скачал скомпилил и поставил. Сложно что ли
в LD_LIBRARY_PATH посмотреть?

Бестолковая статья. Не нашёл там ни одного предложения по делу, только явное незнание возможностей RPM. Похоже, автор просто не знает RPM...

> 3)Нельзя корректно поставить несколько версий одного пакета.

уважаемый, а как же у меня стоят несколько версий одного пакета, который называется kernel?

Он зато Portage толком не знает. Вот скажем это:

"... if you specify --without-x11 in a global configuration file, packages that you install where X11 is optional will install without installing X11."

Интересно, с каких это пор в портежах при сборке использутся опции make'а вместо USE?

>уважаемый, а как же у меня стоят несколько версий одного пакета,
>который называется kernel?
Вам лучше знать.

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

Начинаем вспоминать про unix-way. rpm - отосительно низкоуровневая тулза. Если мы над ней ставим apt - сразу убиваем #1 и практически убиваем #2. #3 вообще решить довольно сложно, в любой ОС. Любое решение, позволяющее ставить одновременно несколько версий, чревато dll hell - или нужно вообще нахрен резко ужесточать дисциплину library versioning, вплоть до гильотины. #4 - да, правда. Но тут вообще сложно, тут нужно всю систему перелопачивать, чтобы гарантировать relocatability package-ей. #5 - а как Вы себе это представляете в общем случае? А если у разных пользователей разные LD_LIBRARY_PATH. Например, скомпилил я, svu из tar.gz какой то libABCDE, запихал в /home/svu/lib и прописал в LD_LIBRARY_PATH. Потом поставил некий пакетик (sudo, вроде, не убивает env), который нашел ее и радостно установился. Что будет дальше - представляете?

Это нетревиальный вопрос. Здесь всё зависит от того, что именно вы хотите сделать. Если вы хотите заставить одну половину приложений использовать старую версию qt, а другую - новую, то я не знаю простого способа как это сделать. Но, в принципе, в rpm есть возможность создания т.н. настраиваемых пакетов, которые можно ставить с любым --prefix.

>#5 - а как Вы себе это представляете в общем случае? А если у разных
>пользователей разные LD_LIBRARY_PATH. Например, скомпилил я, svu из
>tar.gz какой то libABCDE, запихал в /home/svu/lib и прописал в
>LD_LIBRARY_PATH. Потом поставил некий пакетик (sudo, вроде, не
>убивает env), который нашел ее и радостно установился. Что будет
>дальше - представляете?
Ключик сделать "--поискать-не-в-базе" например. Если уж
с ним ставишь нужно понимать что и где будет искаться.
Как парашют запасной чтоб --nodeps не звать.

>Если мы над ней ставим apt - сразу убиваем #1
apt умеет ставить пакеты для котрых не хватает
зависимостей без --nodeps?

От 2 да - apt помогает.

>#3 вообще решить довольно сложно, в любой ОС.
>#4 - да, правда. Но тут вообще сложно, тут нужно всю систему >перелопачивать, чтобы гарантировать relocatability package-ей

>Если вы хотите заставить одну половину приложений использовать >старую версию qt, а другую - новую, то я не знаю простого способа
>как это сделать. Но, в принципе, в rpm есть возможность создания >т.н. настраиваемых пакетов, которые можно ставить с любым --prefix.

О том и речь, что не совсем это тривиальная задача
сделать хороший менеджер пакетов.

Что собственно автор возможно излишне эмоционально
в своей статье изложил.

Помоему все таки большинство пакетов
релоцируемые даже если их создатели об этом
не позаботились.
То есть например можно сделать ключи у rpm
--my-root --package-root
и ставить rpm -i --my-root /home/troll --rpm-root /home/troll/apps
Пускай он файлы в /home/troll/apps/package кладет
а в /home/troll/bin /home/troll/lib симлинки делает.


А как просто с версиями библиотек разобраться
я сам не знаю. Можно здесь пофантазировать.

да все вопли про борьбу с зависимостями это бред из разряда "теперь ваш маздай98 стал стабильнее и безопаснее". шапку юзал с 7.2 и по 9. никаких проблем. если с головй дружить и не корячить систему с нуля, а нужное себе ставить из сорцов или src.rpm то все прекрасно работает. ну пару раз указал --force когда был конфликт файлов и --nodeps когда сносил старую библиотеку и ставил ее новую версию, а от нее зависели другие пакеты. и правильно что он говорит что от чего зависит. так что таким чудакам как это автор - лучше на винфак ходить и не мучать комьюнити

э. батенька checkinstall вам в руки. я ставил разные версии без проблем. а как базис - rpm очень удобен

На тему зависимостей у него есть здравая мысль в конце - должны быть мягкие и жесткие зависимости (soft и hard).

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

Что касается новый QT и KDE - проще подождать пока прогу портируют под новый qt. Держать 2.3.х с 3.0.х и 3.2.х вместе с 3.3.х - расточительная трата ресурсов. Проще тогда подождать с переходом под новый kde,
Для 2.3 обычно есть qt-compat.

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

Они не должны стоять в домашнем каталоге.
А вообще man rpm - каталог точно можно было менять без пересборки.

>Не видит то что поставлено мимо RPM. Из tar.gz
например. Чего орать что libXm нет если я Lesstif
скачал скомпилил и поставил. Сложно что ли
в LD_LIBRARY_PATH посмотреть?

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

--nodeps

Зато не дает сделать из пакетноориентированной системы помойку из самосборных пакетов.

Думаю, ты смог бы поставить - указать новый prefix, --force туда до кучи и каждый раз LD_LIBRARY_PATH при запуске менять и QTDIR другое подставлять.

Смысл в том, что с qt-mt, например, симлинки идут, на которые ориентируются все проги. И для каждой qt они у тебя будут одинаковые, поэтому ставить библиотеки так, как предлагает автор, просто бессмысленно.

>apt умеет ставить пакеты для котрых не хватает
зависимостей без --nodeps?

Хоть смотри перед вопросом, что спрашиваешь. Умеет доставлять пакеты, которых не хватает.

Видишь ли, тут думать надо иногда. Автор этого не умеет.

> Это вообще бред сказочный.

Это вообще-то не бред сказочный, а ты сам живёшь в какой-то сказке.
А проще говоря - не дорос ты ещё до обсуждения таких тем.

> А как же с библиотеками шаренными

Поплач, и всё пройдёт ;) Единственная польза от шареных библиотек -
некоторое (весьма незначительное) уменьшение размера бинарников.
Фича, интересная только для каких-нибудь очень странным образом
скопонованных встроенных систем с ограниченным дисковым пространством.

>Что касается новый QT и KDE - проще подождать пока прогу портируют
>под новый qt.
Ну круто я говорю "мне нужно" ты мне говоршь
тебе не надо этого - подожди пол годика.
Я уж как нибудь сам разберусь чего я хочу, ладно?

>Держать 2.3.х с 3.0.х и 3.2.х вместе с 3.3.х - расточительная трата >ресурсов.
Да прям на копеечном 40g винте мне 100 метров жалко
чтоб у меня все как надо работало.
Но все равно спасибо что посоветовал как сэкономить
1$ =).

>Хоть смотри перед вопросом, что спрашиваешь. Умеет доставлять
>пакеты, которых не хватает.
Еще раз - речь шла как раз о том rpm часто хочет совсем дурацких
зависимостей типа mysql->X. Да soft dependences тут
помогают.

>Они не должны стоять в домашнем каталоге.
От чего же - если сисадмин на работе не дает
ставить в рабочую систему свои проги.
А в home вороти что хочешь.

>А вообще man rpm - каталог точно можно было менять без пересборки
Да не ужели? Куча есть нерелоцируемых пакетов.
Которые в spec файлах абсолютные пути используют.

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

>Зато не дает сделать из пакетноориентированной системы помойку из >самосборных пакетов
О том и речь чтоб rpm позволял много чего а система все еще
не превратилась в помойку. А сейчас
чуть вправо чуть влево от родного набора
пакетов из дистрибутива - и система
действительно превращается в помойку.

>Видишь ли, тут думать надо иногда. Автор этого не умеет.
Уверяю тебя он это умеет =)

> Единственная польза от шареных библиотек - некоторое (весьма незначительное) уменьшение размера бинарников. Фича, интересная только для каких-нибудь очень странным образом скопонованных встроенных систем с ограниченным дисковым пространством.

До тех пор, пока не увижу дистрибут без libc.so - буду считать вышеприведенное изречение бредом. Значительно бОльшим, чем обсуждаемая статья. До этих же времен оставим обсуждение возраста (и грамотности) участников дискусии.

> До тех пор, пока не увижу дистрибут без libc.so

Да как же ты увидишь, когда ты слепой? ;)

> От чего же - если сисадмин на работе не дает ставить в рабочую систему свои проги. А в home вороти что хочешь.

А что мешает в home ставить из tar.gz? Религия? Обычно количество пакетов, которые нужны одному пользователю - весьма скромное и, в подавляющем большинстве случаев, не нуждается в мощном менеджменте. Людей, которые захотели бы поставить весь гном только для себя - настолько мало, что специально затачивать rpm под этот use case - неэффективная трата времени разработчиков. Хуже другое. Встречается много прог, которым нельзя сделать make install не от root - даже если поставишь все префиксы как положено. Сначала нужно с этим разобраться.

> А создатели rpm не предполагали что в природе существуют программы которых нет в моем дистрибутиве?

Сколько угодно. rpm может собрать кто угодно - главное, играть "по правилам".

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

Неправда. Можно использовать "неродные" репозитории (например, jpackage.org) - и жить долго и счастливо. Просто, админ, если уж выбрал систему управления пакетами - изволь придерживаться..

Я не берусь делать выводов об умении автора думать вообще. Но критика, приводимая им, уже неоднократно звучала, а решения, предлагаемые им - создают больше проблем, чем решают.

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

Мягкие и жесткие зависимости...

> На тему зависимостей у него есть здравая мысль в конце - должны быть мягкие и жесткие зависимости

Угу, pre-depends, depends, suggests, recommends.

а что тут такого?

> Если вы хотите заставить одну половину приложений использовать старую версию qt, а другую - новую, то я не знаю простого способа как это сделать.

Дык по жизни работало и работает... Versioned symbols rulez!

про shared libs

> Единственная польза от шареных библиотек - некоторое (весьма незначительное)

раз эдак в 5...

> уменьшение размера бинарников.

Но главное достоинство не в этом. Если исправили баг в zlib, то магическим образом исчезает куча багов в программах, ее использующих. А как их вылавливать, если она статически подлинкована, знает только anonymous (*) (06.04.2004 16:17:43)...

Есть и другая сторона медали :)

Дыра в zlib делает уязвимыми сразу все сервисы, ее исполь.

90% обсуждающих в глаза не видели dpkg, apt, систему сборки из debian... А вот "идеалы" ищут. Что за юношеский максимализм, а?

Sun-ch - Я надеюсь, Вы шутите:)

> Единственная польза от шареных библиотек - некоторое (весьма незначительное) уменьшение размера бинарников

Слинкуй статически KDE и запусти... будешь приятно удивлен количеством используемой памяти ~10-15Мб на каждый бинарник.

> Ключик сделать "--поискать-не-в-базе" например. Если уж с ним ставишь нужно понимать что и где будет искаться. Как парашют запасной чтоб --nodeps не звать.

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

Da ni ganiti vi na RPM. RPM rulit. Debian, slaka i prochee tgz-based
distributivi - laja otkvovennaya. Ret hat RULEZ FAREVA!

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

он извращаться умеет. думать - находить решения. а подводить идеологический базис под свою нелюбовь к чему-то - удел красноглазых. в шапке 7.2 (или 7.3) шли два кде и 2.х и 3.х. как то они это сделали? так что не надо ляля

а ты телепат? и давно ваш цирк в кащенку приехал?

> Единственная польза от шареных библиотек - некоторое (весьма незначительное) уменьшение размера бинарников. Фича, интересная только для каких-нибудь очень странным образом скопонованных встроенных систем с ограниченным дисковым пространством.

Ну-ну... сравни на досуге размер проги собранной статически с динамической. Умножь на количество екзешнишников в системе. Прикинь, сколько копий libc и прочей муйни будет висеть у тебя в памяти при хотя бы 100 запущенных статических процессах. И наконец, расскажи мне легкий способ лечения баги, скажем в zlib, если у тебя все бинарники собраны с ним статически. Ждем-с.

Дык, она так и так их делает уязвимыми, хоть ты статически линкуй, хоть нет =)

А журналируемые ФС и правда не нужны, когда есть softupdates =)

саныч, не говори ерунды

> 1)Нельзя корректно поставить несколько версий одного пакета. Это действительно нужно бывает, _особенно_ в Linux.

Можно. Без проблем.

$ dpkg --status libqt3c102-mt | head -n 2

Package: libqt3c102-mt

Status: install ok installed

$ dpkg --status libqt2 | head -n 2

Package: libqt2

Status: install ok installed

> Не видит то что поставлено мимо RPM. Из tar.gz например.

И не должен. Хрен знает, каким компилятором, с какими флагами, какой версии ЭТО было собрано.

> Чего орать что libXm нет если я Lesstif скачал скомпилил и поставил. Сложно что ли в LD_LIBRARY_PATH посмотреть?

Программы, запущенные от root, НЕ ДОЛЖНЫ смотреть в LD_LIBRARY_PATH.

>Единственная польза от шареных библиотек - некоторое (весьма незначительное) уменьшение размера бинарников.

Сие есть глупость (да простит меня народ за безапелляционность)!

Одно из основных (но не единственных) преймуществ шареных библиотек является возможность апгрейда версий либов без перекомпиляции зависимых бинарников.

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

не надо врать!

> может ты дселект? тому не нужны журналируемые фс

$ mount

/dev/hda1 on / type xfs (rw)

proc on /proc type proc (rw)

devpts on /dev/pts type devpts (rw,gid=5,mode=620)

tmpfs on /dev/shm type tmpfs (rw)

/dev/hda6 on /usr type xfs (ro,nodev,noatime)

/dev/hda7 on /usr/local type xfs (rw,nosuid,nodev,noatime)

/dev/hda8 on /var type reiserfs (rw,nosuid,nodev)

/dev/hda9 on /home type xfs (rw,nosuid,nodev,noatime,usrquota,logbufs=4)

tmpfs on /tmp type tmpfs (rw,nosuid,nodev,size=40m,nr_inodes=512,mode=1777)

Ну и зачем тебе tmpfs on /dev/shm, когда есть tmpfs on /tmp? (Или наоборот)

Сделал бы, что ли, симлинк /tmp -> /dev/shm, чем тратить память попусту. (Я понимаю, что RAM нынче дешев, но не красиво как-то...)

Ой-ёёё...

Опять.

Возвращаемся к нашим баранам.

1. С шаренными библиотеками бинарник жрет меньше памяти (если библиотека уже там).
2. С шаренными библиотеками проще исправить ошибку - не пересобирать все статически слинкованные проги, а собрать лишь одну.
Вспоминаем zlib и плач Борланда и Микрософт о том, что они толком не знают, где у них включена zlib.

>Ну круто я говорю "мне нужно" ты мне говоршь тебе не надо этого - подожди пол годика. Я уж как нибудь сам разберусь чего я хочу, ладно?

Не ставь новый КДЕ - ты же не с оболочкой работаешь, а с прогой? Вот с ней и работай.

На тему home - учу. Врядли у тебя там будет много прог. Заходишь в rpm и распаковываешь его в home. Добавляешь путь в библиотеки и к ~/bin. Тебе счастье.

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

3. Перепиши spec. Это довольно просто.

>А создатели rpm не предполагали что в природе существуют программы которых нет в моем дистрибутиве?

Да, но ты привел библиотеку, которая есть во всех пакетах + есть rpmfind.net rpmseek.com и наверняка есть сообщество твоего дистрибутива, которое собирает программы, не вошедшие в дистриб.

Многие "писатели" собирают сами rpm под suse, rh и mdk.

От трех-четырех прог из исходников, вставших в local, в принципе ничего плохого не будет, ибо о них ты помнишь (у меня так mplayer стоит и gocr). Больше - уже зло.

У меня же не превращается система в помойку - с rh 7.3 до fc 1. Все как надо.

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

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