ihc
26-12-2004, 13:59
Топик создан по мотивам/просьбам трудящихся. Эпиграф обычный, "флейму быть".
Хотел было создать голосование, но потом передумал -- некорректные сравнения дальше пойдут, поэтому просто изложу своё видение различных систем управления пакетами (+ сюда же флейм про портежи от 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).
Сначала небольшое замечание: я -- лицо не беспристрастное, мало того, что я не все системы перечислил и видел в глаза, так я ещё и всю жизнь прожил с 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 умудрились собрать. Только бледнолицый брат...