Системы управления пакетами - Компьютерный форум OSzone.net

Компьютерный форум OSzone.net (http://forum.oszone.net/index.php)

- Новости и флейм из мира *nix (http://forum.oszone.net/forumdisplay.php?f=33)

- - Системы управления пакетами (http://forum.oszone.net/showthread.php?t=43038)

Системы управления пакетами

Топик создан по мотивам/просьбам трудящихся. Эпиграф обычный, "флейму быть".

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

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

Зачем нужна система управления пакетами, наверное, долго объяснять не нужно. В случае "пути самурая" (читай -- сборки из тарболов) рано или поздно сталкиваешься с ситуацией, когда для сборки пакета А нужны библиотеки Б (которая не стоит) и В (стоит старая, нужна новая), а при пересборке В нужно ещё обновить пакет Г, и так ad infinitum. Любой сисадмин, которого попросили _сейчас_ поставить GD2 для отрисовки через ПХП, будет чувствовать себя неловко, пересобирая на живом сервере полсистемы из-за почти 300Кб.

Далее по существу. На данный момент накопился опыт работы с пакетными менеджерами:

deb -- Debian (помимо Debian используется мало где, а зря)
rpm -- RedHat (используется очень часто -- Mdk, RH/FC/ASP, ALT, SuSE etc.)

И системами управления более высокого уровня:

ebuild -- Gentoo
apt -- Debian, ALT, Connectiva (остальные берут на вооружение)

Бздю в рассмотрение не беру, краткое фи я уже высказывал.

1) rpm vs. deb

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

А также в простоте для разработчика. В отличие от deb, сборка пакета требует лишь одного спека, который и описание, и схема сборки, и changelog в одном файле. Сборка rpm легче поддаётся автоматизации, чем deb -- на основе опыта, т.к. уже писал систему сборки разом и под то, и под другое. Для deb нужен отдельный Makefile, и deb не так следит за чистотой сборки: результирующие, а также временные файлы появляются там же, где и авторские.

Из использования deb -- он более чувствителен к ошибкам в [pre|post](install|remove) скриптах. Особенно к pre-remove, ошибка в которых требует ручного вмешательства в свалку скриптов (лежат отдельно в директории). Также мне кажется минусом наличие блокирующих инсталляцию сриптов настройки -- в итоге, _по_умолчанию_ инсталляция не сможет проходить в пакетном режиме, потребуется участие оператора. В случае dist-upgrade на rpm требуется только оценить результаты, в случае deb -- отвлекаться от чашки чая. Говорят, это можно просто изменить, так что -- просто впечатление, не более того.

Итого -- я работаю с rpm больше по историческим причинам. Считаю, что rpm проще как в использовании, так и в упаковке пакетов. Однако, эта простота вытекает из ограничений, которые делают rpm более "тупым" нежели deb, и простота иногда оборачивается дополнительными усилиями пакейджера. Каждый ССЗБ.

2) apt(deb) vs. apt(rpm) vs. ebuild vs. всё остальное.

2.1) apt

На данный момент apt управляет как rpm, так и deb. Исторически на rpm портирован командой Connectiva, впоследствии живое участие в проекте принимали Mandrake (вроде заглохло, но не насовсем), ALT (вовсю двигают), PLD etc. Версия apt для rpm адаптирована к некоторой ограниченности rpm, поэтому умеет не всё из man apt в Debian.

В пакете apt два основных бинарника, apt-get и apt-cache. Первый управляет базами данных по пакетам, заведует установкой и сносом пакетов. Второй выполняет функции поиска по базам данных и вывода некоторой информации по пакетам. Работа ведётся с репозитариями (хранилищами) бинарных пакетов и пакетов для сборки, которые могут располагаться как удалённо (ftp, http, rsync) так и локально, как на смонтированных ФС (file) так и на стопке CD. Для работы с CD есть дополнительная утилитка, apt-cdrom.

Система apt хранит локальные копии баз данных по пакетам (db4). Все операции по установке/удалению пакетов производятся с учётом зависимостей по всей системе, что позволяет избежать конфликтов, через rpm не отслеживаемых. В случае необходимости установки/удаления дополнительных к запрошенным пакетов, они будут предложены к установке/сносу. Скачанные пакеты могут кэшироваться, поддерживается докачка.

2.2) ebuild

С этой системой, в отличие от apt, я работал довольно поверхностно, поэтому буду апеллировать к документации, в основном.

История ebuild идёт от портов FreeBSD и она унаследовала как плюсы, так и минусы этой системы. Ещё раз для случайно заглянувших фанатов бзди: см. топик linux vs. freebsd, я там отписал, почему порты не могут считаться полноценной системой управления пакетами.

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

Ebuild поддерживает всю необходимую функциональность, которая требуется от такой сисемы. Отслеживаются зависимости пакетов как при установке, так и при сносе, резолвятся конфликты пакетов по файлам и зависимостям. Поддерживается как upgrade, так и dist-upgrade.

Основные отличия от apt: основной утиль пользователя один, emerge. Он и ищет, он и ставит, и сносит. Это плюс, правда, иногда смешно получается: снести пакет можно через emerge --unmerge. Главные же отличия вот в чём. Портежи -- это коллекция файлов на диске, которая монтирована или лежит в /usr/portage (по дефолту), а не БД. Как я сейчас посмотрел, на машине рекомого разработчика /usr/portage занимает 1.4Gb, на подсчёт места ушла минута чистого времени. На всякий случай прокомментирую:

*) это место, которое не участвует в работе системы
*) это inodes, которые заняты там, где их можно не занимать
*) это время и траффик, потраченные на синхронизацию портежей

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

Итого, моё резюме по ebuild включает следующее.

*) apt, в отличие от ebuild, может использоваться на небольших и рабочих машинах/серверах. Для упрямых могу посоветовать собрать squid через emerge в чистой системе, которая работает гейтом.
*) я не видел людей, который обновлялись с CD через emerge. В случае apt это рядовая ситуация, а траффик не для всех бесплатен.
*) apt -- лишь надстройка над (deb|rpm), поэтому дальнейшее сравнение переходит на их уровень: emerge используется для сборки пакета в конечной среде (Дима только и делает, что собирает что-то :)), в то время как deb & rpm используются для сборки бинарных пакетов, собранных зачастую в изолированной среде (см. hasher, разработку ALT). Иначе говоря, ebuild не может обеспечить чистоты сборочных зависимостей. Которые, кстати, там строятся руками -- ещё камень в ebuild.

В общем, придирки мои к ebuild не столь велики, но -- blocking. Я никогда не потащу портежи на рабочий гейт/прокси, да ещё собирать там что-либо... Всё, что нужно, собрали до нас. Этим можно и нужно пользоваться, а не тратить машинное время. Прочие минусы касаются разработчиков, однако на пользователях тоже могут сказаться: кривой пакет ударит именно по пользователю. А -- это точно знаю -- системы обязательной пересборки всех пакетов в изолированных средах с отслеживанием конфликтов зависимостей у Gentoo нет. Это берут на себя конечные пользователи, со всеми вытекающими.

2.3) всё остальное

остальные поделия вроде up2date by RH во внимание принимать, позвольте, не буду -- мне хватило полугода (на данный момент) поддержки (не по моей воле) нескольких серверов RH Enterprise Linux. Все, абсолютно все грабли, на которые наступили в своё время разработчики apt в debian, alt, портежей и портов в gentoo, freebsd, все эти грабли разработчики RH умудрились собрать. Только бледнолицый брат...

Мне кажется ты закритиковал gentoo систему, все не так печально как ты пишеш :), система очень хораша, у тех у кого реально широкий канал и процессор сильный этот дистрибутив для них. Я себя к ним не причисляю, но месяц назад пробЫвал поставить систему, было очень необычно, нет тух утилит которые в slackware и все в этом духе. Но всетаки поставил все без X, потом решил что это мне не нужно и снес все.
Есть еще пакетная система которая в slackware обычные tar.gz файлы. Очень удобна, для меня, может я к ней привык. Но в ней все что нужно мне, конечно один минус что нет проверки на зависимости, но это плюс для меня. За все время пользования тяжелых проблем не возникало, очень удобно :)

В защиту Gentoo!
По поводу 1.4 Гб каталога /usr/portage полная фигня. Это размер каталога /usr/portge/distfiles в котором лежат дистрибутивы установленных программ, которые можно смело удалять (если есть возможность при необходимости залить нужный пакет снова), их можно держать на друугом разделе, на другом компьютере, etc. А каталог /usr/portage занимает примерно 80 Мб.

>Ещё -- портежи подразумевают установку из исходников. Дмитрий говорил,
>что есть возможность использовать бинарные пакеты, но в документации на
>сайте я этого не нашёл. Очередной комментарий будет даже не комментарий,
>а просто заметка: OpenOffice.org на не самой слабой машине собирается около
>суток, а исходники его много больше бинарного пакета (для тех, кто считает
>траффик)

Бинарные пакеты устанавливаются элементарно тем же emerge. Но тем и прекасен Gentoo, что все собирается из исходников, конкретно под имеющуюся платформу, хотя ни что не мешает на мощной машине собрать бинарник того же Open Office и перенести на другую. Что касается размера -- да он больше, причем порой значительно, но ведь всегда есть альтернатива -- скачать и установить обычный бинарник, так как это делается в других системах (не через emerge).

>я не видел людей, который обновлялись с CD через emerge.
>В случае apt это рядовая ситуация, а траффик не для всех бесплатен.

Еще одно заблуждение. Уже давно существует нечто наподобие срезов сизифа. Но это не фича, IMHO. Я практически всею систему (включая KDE, Gnome, OpenOffice, etc) перетаскал с работы на флэшке...

>Я никогда не потащу портежи на рабочий гейт/прокси, да ещё собирать
>там что-либо... Всё, что нужно, собрали до нас.

А я никогда не потащу rpm'ы. Только исходники. Даже в RH, Alt и пр.

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

Всегда есть выбор ставить протестированные пакеты либо сырые (что вовсе не значит, что они кривые). Лично я устанавливая эти сырые пакеты еще не разу не столкнулся с кривыми.
И как резюме: просидев 5 лет в рпм-системах и попробовав год назад Gentoo с ее ппортежами, на рпм уже добровольно не вернусь, потому как уже давно забыл что такое неудовлетворенные зависимости. Единственный минус -- это некоторое запаздывание обновления некритичных для системы порежей, например Gimp там все еще 2.0.6 хотя уже существует 2.2, но, думаю, это решится с ростом популярности системы :-) да и ручками можно собрать при крайней необходимости.

BeZoN
давно не видели - с возвращением :)

> И как резюме: просидев 5 лет в рпм-системах и попробовав год назад Gentoo
> с ее ппортежами, на рпм уже добровольно не вернусь, потому как уже давно
> забыл что такое неудовлетворенные зависимости.

Код:

# apt-get check

Чтение списков пакетов... Завершено

Построение дерева зависимостей... Завершено

# echo $?

0

5 лет Вы смотрели не в ту сторону :) Про что и написано в первом посте: я _никогда_ не использую RH по доброй воле, но, попробовав ALT и Debian с apt'ом, я _никогда_ не пересяду на систему, где только и надо что пересобирать пакеты.

Just один вопрос: emerge удаляет _сборочные_ зависимости после сборки пакета? Что-то не помню такого. Продолжение: запоркуа они нужны на _рабочей_ системе? Некий старый bsdшник меня учил k лет назад: в системе не должно быть ничего лишнего. Если пакет не используется для работы, он не должен быть установлен. Он удалял сборочные зависимости руками, после того, как ставил что-либо из портов.

Сегодня же я могу быть уверенным, что в системе нет ничего лишнего, но есть всё необходимое.

Цитата:

Сегодня же я могу быть уверенным, что в системе нет ничего лишнего, но есть всё необходимое.

только это необходимое - установленный универсальный пакет, и, соответственно, может быть немножко слишком избыточней того необходимого, которое получается при make install clean. То есть опять-таки лишнее :)

А я вот джентушные порты к сусе прикрутил! Теперь у меня и apt-get и emerge! Короче полный атас!

mar: Вы видели, как упакован, к примеру, php или perl в ALT или Debian? Рекомендую полюбопытствовать. Смею заверить, пакеты под эти дистрибутивы делаются отнюдь не без башни.

Код:

# apt-cache search ^php

mod_php - Встраиваемый в HTML язык сценариев PHP4 для использования вместе с Apache.

pear - Пакет с рaсширениями для PHP

php - Язык сценариев PHP4

php-base - Package with common data for various PHP packages

php-cgi - The PHP4 HTML-embedded scripting language as a CGI binary.

php-curl - cURL module for PHP4

php-dba - DBA (gdbm, db4) module for PHP4

php-devel - Пакет для разработки расширений PHP4

php-domxml - PHP4 module for support DOM XML

php-fribidi - Fribidi support for PHP4

php-gd2 - GD library support for PHP4

php-imagick - PHP4 wrapper on ImageMagick library

php-imap - IMAP module for PHP4

php-ldap - LDAP module for PHP4

php-libs - Package with common data for various PHP4 packages

php-manual-en - Электронная документация для PHP4

php-manual-ru - Электронная документация для PHP4

php-mbstring - PHP4 module for support multi-byte strings.

php-midgard - Midgard binding for PHP4

php-mime_magic - Mimetype support for PHP4

php-mmcache - Turck MMCache for PHP

php-mysql - MySQL database module for PHP4

php-openssl - OpenSSL module for PHP4

php-pcntl - Process Control Module for PHP (pcntl)

php-pgsql - PostgreSQL database module for PHP4

php-readline - Readline support for PHP4

php-rrdtool - RRDtool library support for PHP4

php-snmp - SNMP module for PHP4

php-sockets - Sockets support for PHP4

php-sybase_ct - Sybase or MS-SQL database module for PHP4

php-xslt - Sablotron XSLT support for PHP4

phpMyAdmin - phpMyAdmin - web-based MySQL administration

phpPgAdmin - Управление PostgreSQL через web

И я не парюсь с исходниками, когда мне нужен модуль php -- просто говорю apt-get install php-snmp, например.

GoRiLLa: 5 баллов! :) Правда, с зависимостями в такой системе будет напряг, но всё равно прикольно :)

ihc
Я около года просидела под debian, сейчас у меня на работе ALT (да и дома стоял, пока диск не приказал долго жить. Совсем. :(). Так что apt-ом пользоваться приходилось. Не стоит лукавить :)- PHP в качестве примера не самая удачная вещь, - тут можно только спорить, где больше по клавишам тыкнуть: сказать, apt-get install, или make all и make install clean (впрочем, можно и в одну строку), - что давольно бессмысленно. Хотя даже тут бОльшая свобода с компилятом - под Free можно PHP скомпилировать, сазу всобачив в него соответствующие библиотеки, а можно дособирать их и приставлять по мере надобности. Но при всем прочем, оптимизация его под конкретную машину сведена к минимуму. Но на свете, если мне не изменяет память, есть и другие примеры, где при компилировании можно как раз уйти от избыточности. При всем уважении к тем, "отнюдь не без башни" товарищам, которые собирают пакеты, по-моему (подчеркиваю - на мой вкус - это сугубое имхо), подстановка готовых блоков, это скорей win, чем unix-way. Впрочем, в данном топике речь идет о разных пакетах, так что прошу прощения за офтоп. Он был вызван легкими походя наездами на BSD вообще и порты в частности :).

mar
>>подстановка готовых блоков, это скорей win, чем unix-way
(*стыдливо пряча глаза*) Угу.

rpm.

Цитата:

5 лет Вы смотрели не в ту сторону Про что и написано в первом посте: я _никогда_ не использую RH по доброй воле, но, попробовав ALT и Debian с apt'ом, я _никогда_ не пересяду на систему, где только и надо что пересобирать пакеты.

Помнится в бытность ALT Master 2.2 я решил обновить sinaptic (вроде так называется гуевая морда для apt), но когда он за собой потащил иксы с кде я решил, что эта затея не совсем удачна. И этот пример не единичен. Поверь это не голые слова. Я просидел в альте пару лет и до сих пор его считаю одним из лучьших дистрибов, но только для начинающих или не требовательных юзеров. Исключительно по причине большого геморроя при сборке пакетов из исходников ;-) В аспе, к примеру, эти проблемы отсутствуют. Но возвращаясь к apt скажу, что им реально устанавливать и обновлять только всякую мелочь с небольшим количеством зависимостей. Хотя сейчас может уже что-то и изменилось. Хорошо если в лучьшую сторону. Кстати, в первом посте ты почему-то не упомянул сюзевский YaST. Очень даже приличная весч для товарисчей перелезающих с детища BG или любителей rpm'ов :-)

Цитата:

И я не парюсь с исходниками, когда мне нужен модуль php -- просто говорю apt-get install php-snmp, например.

А я говорю emerge php-snmp. Получается короче :-)
Ну вот скажи. Есть у меня сервер которому иксы абсолютно ни к чему, а mc совсем не лишний. Однако если ты наберешь apt-get install mc, то он потянет за собой и службу консольной мыши и даже, скорй всего, иксы. Как с этим бороться?
Други! Будьте немного философами. Ведь кто знает, а вдруг при очередном созерцании бегущих строк вывода команды make install у вас родится гениальная идея с которой вы заткнете за пояс господина Ньютона с его законом всемирного тяготения... ;-)

Господа и дамы! Это уже глубоко философский спор из области "кому что нравиться". А о вкусах, как известно, не спорят. Все равно, истины в последней инстанции нам познать и понять не дано.
И, вообще, переношу этот топик во Флейм, где ему самое место.

Цитата:

Судя по всему он для флейма и создавался...
См. первый пост :-)

Цитата:

Топик создан по мотивам/просьбам трудящихся. Эпиграф обычный, "флейму быть".

Я не то, чтобы долго работал с ALT, ASP, SuSE и т.д. Поэтому прошу сильно не пинать. Вставлю свои 5 копеек. RPM-based дистрибутивы, конечно, удобны в плане простоты установки (стянул пакет, установил), но если получается так: стянул пакет, затем еще, затем еще,..., наконец, последний пакет, которые вам вылетят в перебор траффика, то все преимущества сводятся на нет. В source-based дистрибутивах - все хорошо, зависимости должны решаться на этапе emerge, но, опять же, все упирается в траффик. ИМХО, необходимо делать что-то не с разрешением зависимостей, а с искоренением зависимостей как таковых. Только тогда установка станет простой и удобной.

[mzd]
Компилить все статически утопия! IMHO

по-моему тоже. а уж размер такой системы будет....

Здравствуйте , мудрые !
Проблема , однако.
установлен дистрибутив Mandrake 7.2
захотелось перекомпилить ядро.
Из RPM установил kernel-sourse,
при загрузке из RPM glibc-devel вылезла ошибка

не могу распаковать архив cpio error неверный magic

объясните недалекому , что сие значит ?
Ку ?