В чем различия РПМов для разных дистрибутивов (Mandrake, SuSe, Red Hat)? В чем вообще различия РПМ-основанных дистров, кроме как утилит настройки системы?
Что такое /ALTLinux/Sisyphus/ — только с АЛТЛинуксом совместимые пакеты?
Последние комментарии
-
OlegL, 17 декабря в 15:00 →
Перекличка
21
-
REDkiy, 8 июня 2023 года в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
Экология и вегетарианство на благо всем живым существам Планеты.
Различий много.
Начать хотя бы с того, что внутренняя политика дистрибутива о правилах и положениях размещения файлов в дереве зачастую сильно меняется от версии к версии отдельно взятого дистрибутива, а что уж тут говорить о разных…
Далее, бинарные rpm-ки компилируются с учётом а рсачётом на то, что они будут использованы в определённом окружении. Версия glibc, Иксов,… — очень сильно плавает для дистрибутивов одного и того же времи выпуска.
В общем случае — пойдёт или не пойдёт та или иная rpm-ка нужно смотреть отдельно и конкретно для этой rpm.
Особенно внимательно нужно смотреть на суффиксы и зависимости — например, система ALT Linux, поэтому неудивительно, что в ней пакеты будут иметь суффикс -alt. Представим, что уже стоит пакет libpacket-5.3.1-alt6. А хотим поставить программу program-3.6.13-mdk7, которая хочет себе libpacket-5.1.4-mdk4. Хочет — и всё тут. А нафига она нам, спрашивается, если стоит родная, да и версии получше?
И вообще ИМХО RPM — тормознутая технология. Люди, вам трудно сделать
tar xzvf …
cd …
./confgiure
make
make install
??
А если на паре-тройке десятков компов? И так для всех пакетов?
PS: НЕ ОТВЕЧАТЬ! ЭТО — одна из наиболее флеймообразующих граней установки и собпровождения линукса.
Тем, кто не понял, почему… Поймёт это неколько позднее. Пусть даже через пару лет. Обычно требуется меньше…
Зачастую оправдано. Правда, не совсем в такой форме. checkinstall (или софтинка аналогичной функциональности) рулят.
Это ты кому? Мне что ли?!?
Про то, что тома флеймообразующая — согласен.
Однако если подходить не с точки зрения обсуждения целесообразности применения менеджера пакетов, а с точки зрения функциональности конкретного менеджера пакетов (RPM) — то в данном утверждении что-то есть.
В силу ряда причин (одна из которых — элементарно распространенность) RPM — не подарок.
Для установки одного пакета это легко ввести три строчки руками, легко также увидеть чего не хватает ./configure и повторить все для недостающего пакета. Ну а если надо все сделать автоматизированно? «Хочу такую программу» — и тебе находятся все необходимое и ставиться с учетом всех зависимостей. Такое, а также удаление и обновления, можно сделать?
Я вижу подходящим для этого — РПМ
Это не тема для споров на тему избранности линуксовых пользователей, среди которых не место тем кто не может ввести три строчки. Автоматизация в сфере компьютеров — это естественный процесс.
На отдельном конкретном тазике — да. Рулит. Где софт только стаится, и то — со скрипом, где все устаканено на 96-99%%.
Нет. Тем, кто мой постинг не поняли. Пускай малость подумают почему так написал.
Это ещё мягко сказано. Тут, как говорится, ССЗБ. С одним-двумя тазиками ещё можно, а вот с большим количеством — только первое время интересно.
Вряд ли с этим кто спорить будет. Потому как зависимости в rpm явно жесткие — «требуется», нет понятия «предоставляет функцию», «желателен»…
deb в этом плане получше.
Вот и именно, что как только наступает необходимость автоматизации — src.tar.gz, src.tgz и src.tar.bz2 идут мимо кассы.
Ты невнимателен.
Согласен.
Если бы только в этом…
Структуры зависимостей (точнее — временами встречающаяся маразматичность структуры зависимостей) пришедшие в голову разным составителям пакетов — вот головная боль.
Ы? Разберём по полочкам, чтоб больше к таким глупостям не возвращаться.
Положим, стоит 5 серверов, и.. ну. 15-25 рабочих станций, собранных на Slackware.
Имеем checkinstall, настроенный на одной из машин (админской), там же установлен и настроен ftp/nfs для раздачи готовых пакетов. Компиляем, выкладываем, машинки по крону апдейтятся, всё работает. (Ежели у кого другие варианты, более эффективные — высказывайтесь. Иначе, imho — это не админство, а дет.сад.)
Далее.. Чтобы самому не путаться через месяц/два/три/год над тем, где и что лежит, при компиляции нужно выстраивать логичную и понятную структуру расположения файлов. Иначе — бардак, в котором потом сам чёрт ногу сломит.
До кучи: всё это задокументировать, чтобы последователи, которые прийдут после, не сидели и не ломали уже свои головы над тем, что и где — а это, я так подозреваю, мало вообще кто делает.
Итого: спрашивается, а нахрена весь этот труд нужен? Если он уже проделан другими? И выложен в качестве готового_решения?
То, что всё же есть такие ситуации, когда так поступать нужно, это уже другой вопрос. Отдельной статьёй…
Ага. ярчайший пример — это привлечение библиотек иксов в зависимости к консольному mc в ASP Linux 9….
Ну, ты сам просил разбор полетов:
И
Т.е. если продуманность структуры зависимостей (и не только) пакетов априори не является удовлетворительной, то лучше самому собрать пакет.
Про документирование что-где:
Не совсем понял. Либо дока по правилам сборки пакетов и менеджеру пакетов либо обеспечиваемая этим менеджером функциональность.
«Документированность» — это означает, что существует набор описаний, по которому можно другому человеку понять устройство системы. В случае, если пользуемся готовым дистрибутивом с собственной внутренней политикой, часть такой документации уже готова, и, вероятнее всего, последующий работающий на этом месте сможет найти самостоятельно, но, скорее всего, он её уже и так будет знать — при приёме на работу будет поставлен ведь в известность…
PS: чую я, что сие — уже грубый offtopic. тчк.
Где оффтопик? Да еще грубый?
Не Вы ли указывали на то, что структура зависимостей реально существующих пакетов (вопрос насколько соответствующая политике построения дистра) отличается маразматичностью (в случае обсуждаемого менеджера пакетов rpm)?
Так что плохого в том, чтобы собрать пакет пакет самостоятельно как ты считаешь правильным (опционально ознакомившись с доками описывающими идеологию построения используемого дистрибутива).
Я вот скажу свое ИМХО. У меня была система РХ. Там RPM сильно глюканутый. То есть иногда он при установке / удалении пакета виснет и все тут. Ждать можно хоть час. Процесс спит и нифига не делает. После этого чтобы восстановить работоспособность РПМ — менеджера надо ребутицца. Сакс. Теперь у меня слака. Система — супер! Что мне нравится в тарболлах: можно все поменять под себя (это не пустой треп, я уже много раз корректировал Makefile) и весь процесс виден. Это тебе не РПМ с тремя надписями. По поводу множественной установки. Я не админ (кто возмет на работу админа в таком возрасте), но почему нельзя написать bash скрипт который бы автоматизировал установку нужного тарболла на рабочие тачки? А по поводу необходимости систематизации тарболлов. Дейставиельно, рано или поздно они будут разбросаны по компу как хлам. Я полдня потратил на сидение в mc и сваливания этог хлама в отдельную диру по разделам. Но теперь все нормуль. По поводу рекомендаций начинающим: работать с тарболлами надо уметь, так как далеко не все есть в виде РПМ.
Думал. Читал.
Думал.
Пробовал. Думал.
Упоминал. :-)
Ничего плохого в этом, естественно нет, до тех пор, пока:
1) не происходит значительного отклонения от основной политики дистрибутива.
2) все значительные отклонения документируются и, по возможности, обосновываются, почему было сделано именно так.
Основная претензия к сборкам дистрибутивных пакетов возникает тогда, когда: устанавливается автообновление ПО на машину, которая предполагается, что не будет требовать к себе внимания чаще чем пару раз в год. Естественно, что приходится в жанном случает устанавливать автообновление, но на какой источник его нацеливать?
Первое, что приходит на ум, это репозитарий производителя дистрибутива. С одной стороны, вещь довольно-таки правильная, и, если качество и правильность (корректность) обновлений гарантируется (имеется поддержка и заключено соглашение на неё), то, в добавок, является логичной.
В противном случае (отсутствие поддержки, некорректность обновлений) следить и готовить обновления приходится админу. И уже ему приходится производить работу по обеспечению корректного обновления.
Что, собственно, повышает требования к оному.
Т.е. в данном случае — всё будет зависеть от квалификации. И требований поставленной задачи.
А общего решения — и быть не может.
Начиная с третьего сообщения данного обсуждения. :-)