nixp.ru v3.0

29 мая 2017,
понедельник,
14:22:23 MSK

DevOps с компанией «Флант»
anonymous написал 30 января 2004 года в 02:09 (336 просмотров) Ведет себя неопределенно; открыл 1814 темы в форуме, оставил 5575 комментариев на сайте.

В чем различия РПМов для разных дистрибутивов (Mandrake, SuSe, Red Hat)? В чем вообще различия РПМ-основанных дистров, кроме как утилит настройки системы?

Что такое /ALTLinux/Sisyphus/ — только с АЛТЛинуксом совместимые пакеты?

Genie

Различий много.

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

Далее, бинарные rpm-ки компилируются с учётом а рсачётом на то, что они будут использованы в определённом окружении. Версия glibc, Иксов,… — очень сильно плавает для дистрибутивов одного и того же времи выпуска.

В общем случае — пойдёт или не пойдёт та или иная rpm-ка нужно смотреть отдельно и конкретно для этой rpm.

Особенно внимательно нужно смотреть на суффиксы и зависимости — например, система ALT Linux, поэтому неудивительно, что в ней пакеты будут иметь суффикс -alt. Представим, что уже стоит пакет libpacket-5.3.1-alt6. А хотим поставить программу program-3.6.13-mdk7, которая хочет себе libpacket-5.1.4-mdk4. Хочет — и всё тут. А нафига она нам, спрашивается, если стоит родная, да и версии получше?

Longobard

И вообще ИМХО RPM — тормознутая технология. Люди, вам трудно сделать

tar xzvf …

cd …

./confgiure

make

make install

??

Genie
LONGOBARD
И вообще ИМХО RPM — тормознутая технология. Люди, вам трудно сделать

tar xzvf …

cd …

./confgiure

make

make install

??

А если на паре-тройке десятков компов? И так для всех пакетов?

PS: НЕ ОТВЕЧАТЬ! ЭТО — одна из наиболее флеймообразующих граней установки и собпровождения линукса.

Тем, кто не понял, почему… Поймёт это неколько позднее. Пусть даже через пару лет. Обычно требуется меньше…

Anarchist
Genie
А если на паре-тройке десятков компов? И так для всех пакетов?

Зачастую оправдано. Правда, не совсем в такой форме. checkinstall (или софтинка аналогичной функциональности) рулят.

Genie
НЕ ОТВЕЧАТЬ! ЭТО — одна из наиболее флеймообразующих граней установки и собпровождения линукса.

Тем, кто не понял, почему… Поймёт это неколько позднее. Пусть даже через пару лет. Обычно требуется меньше…

Это ты кому? Мне что ли?!?

Про то, что тома флеймообразующая — согласен.

Однако если подходить не с точки зрения обсуждения целесообразности применения менеджера пакетов, а с точки зрения функциональности конкретного менеджера пакетов (RPM) — то в данном утверждении что-то есть.

В силу ряда причин (одна из которых — элементарно распространенность) RPM — не подарок.

anonymous
LONGOBARD
И вообще ИМХО RPM — тормознутая технология. Люди, вам трудно сделать

tar xzvf …

cd …

./confgiure

make

make install

??

Для установки одного пакета это легко ввести три строчки руками, легко также увидеть чего не хватает ./configure и повторить все для недостающего пакета. Ну а если надо все сделать автоматизированно? «Хочу такую программу» — и тебе находятся все необходимое и ставиться с учетом всех зависимостей. Такое, а также удаление и обновления, можно сделать?

Я вижу подходящим для этого — РПМ

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

Genie
Anarchist
Зачастую оправдано. Правда, не совсем в такой форме. checkinstall (или софтинка аналогичной функциональности) рулят.

На отдельном конкретном тазике — да. Рулит. Где софт только стаится, и то — со скрипом, где все устаканено на 96-99%%.

Anarchist
Это ты кому? Мне что ли?!?

Нет. Тем, кто мой постинг не поняли. Пускай малость подумают почему так написал.

Anarchist
Про то, что тома флеймообразующая — согласен.

Это ещё мягко сказано. Тут, как говорится, ССЗБ. С одним-двумя тазиками ещё можно, а вот с большим количеством — только первое время интересно.

Anarchist
Однако если подходить не с точки зрения обсуждения целесообразности применения менеджера пакетов, а с точки зрения функциональности конкретного менеджера пакетов (RPM) — то в данном утверждении что-то есть.

В силу ряда причин (одна из которых — элементарно распространенность) RPM — не подарок.

Вряд ли с этим кто спорить будет. Потому как зависимости в rpm явно жесткие — «требуется», нет понятия «предоставляет функцию», «желателен»…

deb в этом плане получше.

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

Вот и именно, что как только наступает необходимость автоматизации — src.tar.gz, src.tgz и src.tar.bz2 идут мимо кассы.

Anarchist
Genie
На отдельном конкретном тазике — да. Рулит. Где софт только стаится, и то — со скрипом, где все устаканено на 96-99%%.

Ты невнимателен.

When make install is done, CheckInstall will create a Slackware, RPM or Debian compatible package and install it with Slackware’s installpkg, «rpm -i» or Debian’s «dpkg -i» as appropriate, so you can view it’s contents with pkgtool («rpm -ql» for RPM users or «dpkg -l» for Debian) or remove it with removepkg («rpm -e«|»dpkg -r»).


Genie
С одним-двумя тазиками ещё можно, а вот с большим количеством — только первое время интересно.

Согласен.

Genie
Вряд ли с этим кто спорить будет. Потому как зависимости в rpm явно жесткие — «требуется», нет понятия «предоставляет функцию», «желателен»…

deb в этом плане получше.

Если бы только в этом…

Структуры зависимостей (точнее — временами встречающаяся маразматичность структуры зависимостей) пришедшие в голову разным составителям пакетов — вот головная боль.

Genie
Anarchist
Ты невнимателен.

Ы? Разберём по полочкам, чтоб больше к таким глупостям не возвращаться.

Положим, стоит 5 серверов, и.. ну. 15-25 рабочих станций, собранных на Slackware.

Имеем checkinstall, настроенный на одной из машин (админской), там же установлен и настроен ftp/nfs для раздачи готовых пакетов. Компиляем, выкладываем, машинки по крону апдейтятся, всё работает. (Ежели у кого другие варианты, более эффективные — высказывайтесь. Иначе, imho — это не админство, а дет.сад.)

Далее.. Чтобы самому не путаться через месяц/два/три/год над тем, где и что лежит, при компиляции нужно выстраивать логичную и понятную структуру расположения файлов. Иначе — бардак, в котором потом сам чёрт ногу сломит.

До кучи: всё это задокументировать, чтобы последователи, которые прийдут после, не сидели и не ломали уже свои головы над тем, что и где — а это, я так подозреваю, мало вообще кто делает.

Итого: спрашивается, а нахрена весь этот труд нужен? Если он уже проделан другими? И выложен в качестве готового_решения?

То, что всё же есть такие ситуации, когда так поступать нужно, это уже другой вопрос. Отдельной статьёй…

Anarchist
Согласен.

Если бы только в этом…

Структуры зависимостей (точнее — временами встречающаяся маразматичность структуры зависимостей) пришедшие в голову разным составителям пакетов — вот головная боль.

Ага. ярчайший пример — это привлечение библиотек иксов в зависимости к консольному mc в ASP Linux 9….

Anarchist

Ну, ты сам просил разбор полетов:

Genie
Ы? Разберём по полочкам, чтоб больше к таким глупостям не возвращаться.

Положим, стоит 5 серверов, и.. ну. 15-25 рабочих станций, собранных на Slackware.

Имеем checkinstall, настроенный на одной из машин (админской), там же установлен и настроен ftp/nfs для раздачи готовых пакетов. Компиляем, выкладываем, машинки по крону апдейтятся, всё работает. (Ежели у кого другие варианты, более эффективные — высказывайтесь. Иначе, imho — это не админство, а дет.сад.)

Далее.. Чтобы самому не путаться через месяц/два/три/год над тем, где и что лежит, при компиляции нужно выстраивать логичную и понятную структуру расположения файлов. Иначе — бардак, в котором потом сам чёрт ногу сломит.

До кучи: всё это задокументировать, чтобы последователи, которые прийдут после, не сидели и не ломали уже свои головы над тем, что и где — а это, я так подозреваю, мало вообще кто делает.

Итого: спрашивается, а нахрена весь этот труд нужен? Если он уже проделан другими? И выложен в качестве готового_решения?

То, что всё же есть такие ситуации, когда так поступать нужно, это уже другой вопрос. Отдельной статьёй…

И

Genie
Ага. ярчайший пример — это привлечение библиотек иксов в зависимости к консольному mc в ASP Linux 9….

Т.е. если продуманность структуры зависимостей (и не только) пакетов априори не является удовлетворительной, то лучше самому собрать пакет.

Про документирование что-где:

Не совсем понял. Либо дока по правилам сборки пакетов и менеджеру пакетов либо обеспечиваемая этим менеджером функциональность.

Genie
Anarchist
Т.е. если продуманность структуры зависимостей (и не только) пакетов априори не является удовлетворительной, то лучше самому собрать пакет.

Про документирование что-где:

Не совсем понял. Либо дока по правилам сборки пакетов и менеджеру пакетов либо обеспечиваемая этим менеджером функциональность.

«Документированность» — это означает, что существует набор описаний, по которому можно другому человеку понять устройство системы. В случае, если пользуемся готовым дистрибутивом с собственной внутренней политикой, часть такой документации уже готова, и, вероятнее всего, последующий работающий на этом месте сможет найти самостоятельно, но, скорее всего, он её уже и так будет знать — при приёме на работу будет поставлен ведь в известность…

PS: чую я, что сие — уже грубый offtopic. тчк.

Anarchist
Genie
«Документированность» — это означает, что существует набор описаний, по которому можно другому человеку понять устройство системы. В случае, если пользуемся готовым дистрибутивом с собственной внутренней политикой, часть такой документации уже готова, и, вероятнее всего, последующий работающий на этом месте сможет найти самостоятельно, но, скорее всего, он её уже и так будет знать — при приёме на работу будет поставлен ведь в известность…

PS: чую я, что сие — уже грубый offtopic. тчк.

Где оффтопик? Да еще грубый?

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

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

Longobard

Я вот скажу свое ИМХО. У меня была система РХ. Там RPM сильно глюканутый. То есть иногда он при установке / удалении пакета виснет и все тут. Ждать можно хоть час. Процесс спит и нифига не делает. После этого чтобы восстановить работоспособность РПМ — менеджера надо ребутицца. Сакс. Теперь у меня слака. Система — супер! Что мне нравится в тарболлах: можно все поменять под себя (это не пустой треп, я уже много раз корректировал Makefile) и весь процесс виден. Это тебе не РПМ с тремя надписями. По поводу множественной установки. Я не админ (кто возмет на работу админа в таком возрасте), но почему нельзя написать bash скрипт который бы автоматизировал установку нужного тарболла на рабочие тачки? А по поводу необходимости систематизации тарболлов. Дейставиельно, рано или поздно они будут разбросаны по компу как хлам. Я полдня потратил на сидение в mc и сваливания этог хлама в отдельную диру по разделам. Но теперь все нормуль. По поводу рекомендаций начинающим: работать с тарболлами надо уметь, так как далеко не все есть в виде РПМ.

Genie

Думал. Читал.

Думал.

Пробовал. Думал.

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

Упоминал. :-)

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

Ничего плохого в этом, естественно нет, до тех пор, пока:

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

2) все значительные отклонения документируются и, по возможности, обосновываются, почему было сделано именно так.

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

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

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

Что, собственно, повышает требования к оному.

Т.е. в данном случае — всё будет зависеть от квалификации. И требований поставленной задачи.

А общего решения — и быть не может.

Genie
Anarchist
Где оффтопик? Да еще грубый?

Начиная с третьего сообщения данного обсуждения. :-)