IMHO, давно пора.

и за стандарт взять пакеты тар-гз и дистриб - Слакварь!

2anonymous (*) (2001-07-03 13:57:25.0)

дело говоришь. ;)

А какая разница в каком формате будут пакеты, если не секрет?

И самое главное - отменить все эти гадкие имена пользователей,
и привилегии !! Есть только один истинный юзер, и АНОНИМОУС имя ему!!!

Ага, сделать, чтоб линукс был только один, и имя ему - FreeBSD :)

Да, бардак давно пора устранить. Просто хотелось, чтобы бинарники работали на любом Линукс. Но боюсь, этого не будет...

> А какая разница в каком формате будут пакеты, если не секрет?
Секрет. А знает его только тот, у кого на памяти 3 или 4 изменения
в формате rpm, приводящих к полной несовместимости даже в рамках дитрибутивов
одного вендора. Давить эту суксь.

Бардак устранять надо, но LSB не та штука, которая сможет это сделать.
Ибо пропагандирует создавать среднеарифметическое дерьмо. Берут за основу
ублюдочный Hat, смотрят чего не хватает другим, добавляют еще дерьма, убирают
то, что совсем хреново пахнет - и вот вам LSB! Кушайте на здоровье.

А причем здесь формат пакетов и состав дистривутивов?

Стандартизация - это требование времени. Хотя, конечно, немного жаль...

Что-то я не понял... Они там RPM как PM используют???? Скажите мне что я ошибся... :)

"Ага, сделать, чтоб линукс был только один, и имя ему - FreeBSD :)" Ага, а CУБД к ниму ты напишеш?

" Секрет. А знает его только тот, у кого на памяти 3 или 4 изменения в формате rpm, приводящих к полной несовместимости даже в рамках дитрибутивов одного вендора. Давить эту суксь." А поподробнее? Или ля-ля тополя?

>Что-то я не понял... Они там RPM как PM используют???? Скажите мне
>что я ошибся... :)
>yozh (*) (2001-07-03 16:34:01.0)

Во первых это не стандарт а "драфт".
А во вторых, там написано следующее:

"Chapter 13. Software Installation"
( http://www.linuxbase.org/spec/gLSB/gLSB/swinstall.html )

( перевод мой )
"Аппликации должны распространятся в формате RPM, как указано в
приложении к [ книге ] "Maximum RPM", с ниже перечисленными ограничениями [1]

Дистрибутивы должны обеспечивать механизм инсталляции аппликаций
в данном формате, с ниже перечисленными ограничениями [2]"

Идем в "ограничения", смотрим.
Ограничение но. 1 ограничивает RPM как формат описанный в книге, и
не более того.
Ограничение но. 2 говорит о свободе выбора авторами дистрибутива
своего собственного формата.

Итого: переводить Slackware и Debian на RPM никто не собирается, но
для совместимости с стандартом, пакеты в формате RPM должны быть
"устанавлиемыми"..

Итак: Вы не совсем правы:)

Лучше бы сделали так, чтобы кернел менялся от версии к версии (что собственно сейчас и происходит), но модули, скомпиленные под одно можно было бы без проблем запустить на другом (хотя бы без backward compatiblity)

ну чего расшумельсь
хорошее начинание, согласен
но все равно "полной гармонии" НЕ БУДЕТ
это возможно только когда владелец один

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

Надо передать все права на разработку ядра Linux и производство дистрибутивов фирме Microsoft. Серьёзно. Они бардак быстро устранят.

А чем собс-но RPM не устраивает ?? IMHO вполне удобная вещь.

Никто и никогда не стандартизирует Linux. Такова его природа.

Bluesman

>Серьёзно. Они бардак быстро устранят.

Вместе с GNU/Linux

Много раз видел, что RPM ругают.

Hи разу не видел настоящих аргументов.

Может кто-нибуть ещё раз поругать RPM? Hо с одним условием:
ругатель должен заявить - "Я не только просмотрел man rpm,
но и ИЗУЧИЛ книжку 'Maximum RPM', и вот мои претензии
к этому менеджеру пакетов:".

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

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

Есть (лично у меня) одна ОЧЕНЬ важная претензия к RPM:
НЕНАВИЖУ, КОГДА ЖЕЛЕЗКА ПЫТАЕТСЯ ЗАЯВИТЬ, ЧТО ОНА УМНЕЕ МЕНЯ!!!
Одну такую систему я знаю - MUST DIE называется.
Поэтому (хоть бы чисто и из желания "сделать наоборот") принципиально отвергаю RPM.

А может железка-то и права? ;-)

Да софт из RPM устанавливать - хуже нет ничего

Вот попросил один знакомый помочь DIA на шапокляке обновить. Так пришлось обновить почти весь GNOME. А я у себя на слаке поставил GTK+ и libxml, и встала Dia как миленькая...

RPM est sucks, potomy chto
1. mne iz *.tar.gz (.spec netu) sobrat .deb proche chem rpm.
2. Kluchi ne ochevidni (naprimer dpkg --list eto ponyatno,
a rpm -q tra-la-la ne intuitivno (IMHO))
3. Nuzhno pisat dlinnie spec. V dpkg u menya vse pishut scripti :).
4. U mneya stoit v debiane rpm 3.x, iz za etogo ne mogu chitat
rpm 4.x ( mne pofigu, no eto ne pravilno).
5. Medlenno otkivaetsa soderzhimoe rpm v mc (enter hazat a potom na
cto-to.cpio).
6. Ochen mnogo kluchey, hotya realno nuzhno shtuk 7. (IMHO).
Za eto ya ego ne lublu.
Sorry za trans. links

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

>>Да, бардак давно пора устранить. Просто хотелось, чтобы бинарники работали на любом Линукс. Но боюсь, этого не будет..

бинарные файлы не зависят от дистрибутива, а зависят тока от используемых либ ($ldd ~/bin/hello_world). Поетому, в проги для работы требуют наличия либ, и чтобы пути к ним были прописаны в /etc/ld.so.conf. (cсоответсвенно /sbin/ldconfig был постоен файл /etc/ld.so.cache). Сушествуют еще переменные окружения типа LD_PRELOAD_PATH и тд. но это ваще не для среднего ума типичного красноглазого линуксоида. Далее, читаем INSTALL к любому пакету, и видем там что-то типа лучше конечно ставить под РедХат, но вообще-то нужны для работы kernel >2.2.x glibc >2.1.x и еще чего-то там. Если все это у вас есть, не сомневайтесь, прога работать будет под чем угодно. Если не работаеть, идем в инет и читаем учебники. Правда проблема есть в том , что могие либы и ядро "чуть, чуть" дорабатываються создателями дистрибутива, в следствии чего многие функции в либах есть, но работают не корректно (причин этому много). Поэтому, не зависимо от дистра рекомендуеться самостоятельно собрать и поставить как минимум 3 вещи. Компилятор(gcc), glibc, ну и кернел с ftp.kernel.org. Кроме того, попутно вы все это можете собрать под свой проц(или процы) получив хоть и не большой, но выграш от своей архитектуры.

>>Лучше бы сделали так, чтобы кернел менялся от версии к версии (что собственно сейчас и происходит), но модули, скомпиленные под одно можно было бы без проблем запустить на другом (хотя бы без backward compatiblity)

На это уже частично ответили выше, но добавлю. Для того что-бы так было нужно заморозить API, т.е. фиксировать кернел хедеры которые обычно лежать в /usr/src/linux/include/. Т.е практически связать руки разработчикам. Что может быть когда нибудь и будет, но точно еще не скоро. Так что конечно минус, но те кто сами могут собрать ядро и не имеют специфических железяк от этого совершенно не страдають.

P.S. Сорри за лекцию у тех кому вышенаписанное известно. Но если не тыкать носом, многие неучи будут и дальше считать себя крутыми хацкерами.

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

Кстати, анониму, не умеющему писать по русски:
$ rpm --version
RPM версия 3.0.6

И я могу утанавливать RPM-ки 4-ой версии... Наверное как обычно, сделал что-нибудь не так...

2AffereuxChien: hm, u tebya zhe spring2001,
tam razve ne vse posledniee versii softa?
Potom s toboy ya uzhe sporil v irc :).
PS u menya rpm 3.0.3, i ne chitaet on rpm ot spring edition naprimer.

A vot chto budet elsi ya napishu po russki чУЕН лх! (links)
PPS Ya so slaki slez imenno izza togo chto ne bilo packetov

Paranoic.

> tam razve ne vse posledniee versii softa?
Последние, но "с головой", не всё самое последнее есть самое лучшее.
К тому же я не страдаю апгрейдоманией....

> po russki чУЕН лх! (links)
Это зависит от того, какой ногой настроен "русский апач" (давить) и как броузер работает с кодировками.

RPM vs DEB - песнь отдельная, deb мне кое в чём даже больше нравится...

P.S. Эх, пойду я Кешу паре мудростей научу, отцеплюсь от рабочего сервера, да отдыхать...
P.P.S. Судя по Кеше AI теперь переводится, как Applied Ignorance.

RPM - одназначно суксь. Тут кое-кто удивленные глаза делает, типа какая такая несовместимость.
Обнаковенная. Сукось к сукоси прилипает. Маздайный rpm использует маздайный db.
Только маздайный db никогда не стоит на месте, а периодически реинкарнируется
в db1, db2, db3 и т.д. А каждая новая версия несовместима с предыдущей.
Соответственно маздайный rpm тоже становится несовместим сам с собой.
А ведь если подумать, почти все, что он впихивает в базу уже представлено
файловой системой - что может быть лучше?

Но и это не все. От версии к версии меняется формат спеков, и чтоб пересобрать
стрый srpm нужно изрядно править его спек и каждый раз материться - ну что еще
этой ... не хватает.

А как вам нравится такая конструкция:

rpm -qp /usr/src/RPMS/i686/* --qf "[%-25{=NAME} %{PROVIDES}\n]" | grep something

Лично мне не очень.

Еще к примеру нужно вам установить систему rpm от другого вендора. Хорошо,
если пакет простенький и не имеет длинных зависимостей. А если нет,
то без --nodeps --ignore-arch --force вам не обойтись. Но тут совсем
уж очевидный вопрос возникает: а на хрена мне этот бесполезный матюгальник,
который кроме как ругаться ничего не может?

Короче, одно слово - СУКОСЬ.

Или вот вам еще классический пример геморроя с этим RPM.
Мне нужно поставить пакет expect на сервере, на котором нет и не требуется иметь X-ы.
Казалось бы скажи rpm -ivh expect.rpm и все дела... Ан не тут то было.
Expect требует tcl. Ладно, дурдом конечно, но ставим. Опаньки... tcl требует tk!
Ладно, материмся и ставим. Херакс, теперь нас просят уже поставить XFree86-libs...
Oops, паровозик однако получился, говоря в терминах преферанса.

> Правда проблема есть в том , что могие либы и ядро "чуть, чуть"
> дорабатываються создателями дистрибутива

А как насчет базовых утилит? Никогда не сталкивался с тем, что useradd/groupadd
в редхате мягко говоря не такой как у всех? Вот за такие фокусы нужно
вообще руки отрывать паршивцам.

Шапка вобше отдельная песня. Ни в коем случае не кричу что она кривая, просто она дальше всех ушла от классического Юникса. Очень много переделано самими редхатовцами. Лично меня, больше всего выводит из себя даже не ублюдочный RPM а пути, куда по умолчанию ложат многие пакеты. В принципе, когда работаешь тока с шапкой это не проблема, ну какая разница где лежать бинарники, хоть в /etc, а бы пути были прописаны. К этому привыкаешь. Проблема начинает чувствоваться когда работать приходиться с другими Юниксами, и чем их (других Юниксов) ты видешь/работаешь больше, тем Краснее становить шапка от матов. Сам когда то давено начинал с Шапки, потом год ушло на выбивание из головы Красношапочных путей,

> RPM версия 3.0.6. И я могу утанавливать RPM-ки 4-ой версии... Наверное как обычно, сделал что-нибудь не так...

Если реч идет о RedHat, то правильный RPM 4 для RH6 лежит в апдейтах.

> Соответственно маздайный rpm тоже становится несовместим сам с собой.

RPM поддерживает совместимость новых версий со старыми. При апдейте просто конвертируется старая база в новый формат. Проверено последовательным online апдейтом 5.x -> 6.x -> 7.x.

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

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

> От версии к версии меняется формат спеков

ну жизнь на месте тоже не стоит

> Еще к примеру нужно вам установить систему rpm от другого вендора.

бинарной совместимости между вендорами никто (а тем более RedHat) никому не обещал.

XFree86-libs это один из базовых пакетов и от него ты всеравно никуда не денешься. Потому RH особенно и не заботился о разделении tcl на чисто tcl и tcl с X'ами.

PS: для тех, кто совсем в танке - установка XFree86-libs не влечет за собой установку X'ов.

> Никогда не сталкивался с тем, что useradd/groupadd в редхате мягко говоря не такой как у всех?

В RedHat команды useradd/groupadd такие, как принято в System V. Такие же, как в коммерческих юниксах.

> потом год ушло на выбивание из головы Красношапочных путей

Это не только инициатива RedHat, пути описаны в стандарте на файловую систему, которому пытаются теперь соответствовать все дистрибутивы Linux.

2 всем кому РПМ жить мешает:
Если хочешь порядок в системе, то rpm позволяет его установить (как и др менеджеры пакетов), а если порядок тебе не нужен, а хочешь установить прогу и чтобы тебе, никто не мешал, то "флаг тебе в руку, барабан на шею" тогда:
./configure
make
make install
"enjoe"
или
rpm -ivh --nodeps --force la-la-la
"enjoe"
но за работоспособность проги никто не ручается, как и за возможность снести ненужную прогу при первом варианте.
И если у меня например 10 серверов, то помнить где-что установлено ой как сложно.
А недоработанность РПМ это отдельная песня, но ведь все мы знаем, что самые рабочие программы только в Вындузе :-)