|
Компьютерный форум OSzone.net » Linux и FreeBSD » Новости и флейм из мира *nix » Системы управления пакетами |
|
Системы управления пакетами
|
![]() Старожил Сообщения: 194 |
Топик создан по мотивам/просьбам трудящихся. Эпиграф обычный, "флейму быть".
Хотел было создать голосование, но потом передумал -- некорректные сравнения дальше пойдут, поэтому просто изложу своё видение различных систем управления пакетами (+ сюда же флейм про портежи от 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 используется для сборки пакета в конечной среде (Дима только и делает, что собирает что-то ![]() В общем, придирки мои к ebuild не столь велики, но -- blocking. Я никогда не потащу портежи на рабочий гейт/прокси, да ещё собирать там что-либо... Всё, что нужно, собрали до нас. Этим можно и нужно пользоваться, а не тратить машинное время. Прочие минусы касаются разработчиков, однако на пользователях тоже могут сказаться: кривой пакет ударит именно по пользователю. А -- это точно знаю -- системы обязательной пересборки всех пакетов в изолированных средах с отслеживанием конфликтов зависимостей у Gentoo нет. Это берут на себя конечные пользователи, со всеми вытекающими. 2.3) всё остальное остальные поделия вроде up2date by RH во внимание принимать, позвольте, не буду -- мне хватило полугода (на данный момент) поддержки (не по моей воле) нескольких серверов RH Enterprise Linux. Все, абсолютно все грабли, на которые наступили в своё время разработчики apt в debian, alt, портежей и портов в gentoo, freebsd, все эти грабли разработчики RH умудрились собрать. Только бледнолицый брат... |
|
Отправлено: 13:59, 26-12-2004 |
Пользователь Сообщения: 56
|
Профиль | Отправить PM | Цитировать Цитата:
Цитата:
Ну вот скажи. Есть у меня сервер которому иксы абсолютно ни к чему, а mc совсем не лишний. Однако если ты наберешь apt-get install mc, то он потянет за собой и службу консольной мыши и даже, скорй всего, иксы. Как с этим бороться? Други! Будьте немного философами. Ведь кто знает, а вдруг при очередном созерцании бегущих строк вывода команды make install у вас родится гениальная идея с которой вы заткнете за пояс господина Ньютона с его законом всемирного тяготения... ;-) |
||
Последний раз редактировалось BeZoN, 30-12-2004 в 08:44. Отправлено: 08:34, 30-12-2004 | #11 |
Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети. Если же вы забыли свой пароль на форуме, то воспользуйтесь данной ссылкой для восстановления пароля. |
![]() Юниксоид Сообщения: 3001
|
Профиль | Отправить PM | Цитировать Господа и дамы! Это уже глубоко философский спор из области "кому что нравиться". А о вкусах, как известно, не спорят. Все равно, истины в последней инстанции нам познать и понять не дано.
И, вообще, переношу этот топик во Флейм, где ему самое место. |
------- Отправлено: 08:40, 30-12-2004 | #12 |
Пользователь Сообщения: 56
|
Профиль | Отправить PM | Цитировать Цитата:
См. первый пост :-) Цитата:
|
||
Отправлено: 08:48, 30-12-2004 | #13 |
Линуксоид-стакановец Сообщения: 2391
|
Профиль | Отправить PM | Цитировать Я не то, чтобы долго работал с ALT, ASP, SuSE и т.д. Поэтому прошу сильно не пинать. Вставлю свои 5 копеек. RPM-based дистрибутивы, конечно, удобны в плане простоты установки (стянул пакет, установил), но если получается так: стянул пакет, затем еще, затем еще,..., наконец, последний пакет, которые вам вылетят в перебор траффика, то все преимущества сводятся на нет. В source-based дистрибутивах - все хорошо, зависимости должны решаться на этапе emerge, но, опять же, все упирается в траффик. ИМХО, необходимо делать что-то не с разрешением зависимостей, а с искоренением зависимостей как таковых. Только тогда установка станет простой и удобной.
|
------- Отправлено: 19:27, 09-02-2005 | #14 |
Ветеран Сообщения: 659
|
Профиль | Отправить PM | Цитировать [mzd]
Компилить все статически утопия! IMHO |
Отправлено: 17:02, 11-02-2005 | #15 |
just mar Сообщения: 3904
|
Профиль | Отправить PM | Цитировать по-моему тоже. а уж размер такой системы будет....
|
Отправлено: 18:41, 11-02-2005 | #16 |
Новый участник Сообщения: 7
|
Профиль | Отправить PM | Цитировать Здравствуйте , мудрые !
Проблема , однако. установлен дистрибутив Mandrake 7.2 захотелось перекомпилить ядро. Из RPM установил kernel-sourse, при загрузке из RPM glibc-devel вылезла ошибка не могу распаковать архив cpio error неверный magic объясните недалекому , что сие значит ? Ку ? |
Отправлено: 22:59, 13-02-2005 | #17 |
![]() |
Участник сейчас на форуме |
![]() |
Участник вне форума |
![]() |
Автор темы |
![]() |
Сообщение прикреплено |
| |||||
Название темы | Автор | Информация о форуме | Ответов | Последнее сообщение | |
CMD/BAT - Подскажите код для работы с tcp/ip пакетами | LINCOLN | Программирование и базы данных | 3 | 18-07-2009 11:57 | |
FreeBSD - создание DVD с пакетами для FreeBSD | Kirulator | Общий по FreeBSD | 3 | 08-05-2009 11:31 | |
Ошибка - При потребности войти в Свойства системы или Панель управления, перезаргужаеться... | CnyH9I | Microsoft Windows 2000/XP | 2 | 04-03-2009 12:17 | |
[решено] Обмен пакетами с неизвестным IP. | Grey_rnd | Лечение систем от вредоносных программ | 21 | 09-11-2008 13:49 | |
Установка - Проблема с sysprep и пакетами драйверов Bashrat the Sneaky | Bucher | Автоматическая установка Windows 2000/XP/2003 | 0 | 19-11-2007 04:43 |
|