Имя пользователя:
Пароль:  
Помощь | Регистрация | Забыли пароль?  | Правила  

Компьютерный форум OSzone.net » Linux и FreeBSD » Новости и флейм из мира *nix » Системы управления пакетами

Ответить
Настройки темы
Системы управления пакетами
ihc ihc вне форума

Аватара для ihc

Старожил


Сообщения: 194
Благодарности: 2

Профиль | Сайт | Отправить PM | Цитировать


Изменения
Автор: ihc
Дата: 26-12-2004
Описание: орфографичесике ошибки
Топик создан по мотивам/просьбам трудящихся. Эпиграф обычный, "флейму быть".

Хотел было создать голосование, но потом передумал -- некорректные сравнения дальше пойдут, поэтому просто изложу своё видение различных систем управления пакетами (+ сюда же флейм про портежи от 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 умудрились собрать. Только бледнолицый брат...

Отправлено: 13:59, 26-12-2004

 

Пользователь


Сообщения: 56
Благодарности: 0

Профиль | Отправить PM | Цитировать


Цитата:
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 у вас родится гениальная идея с которой вы заткнете за пояс господина Ньютона с его законом всемирного тяготения... ;-)

Последний раз редактировалось BeZoN, 30-12-2004 в 08:44.


Отправлено: 08:34, 30-12-2004 | #11



Для отключения данного рекламного блока вам необходимо зарегистрироваться или войти с учетной записью социальной сети.

Если же вы забыли свой пароль на форуме, то воспользуйтесь данной ссылкой для восстановления пароля.


Аватара для Belansky

Юниксоид


Сообщения: 3001
Благодарности: 45

Профиль | Отправить PM | Цитировать


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

-------
Косово je Србиjа!


Отправлено: 08:40, 30-12-2004 | #12


Пользователь


Сообщения: 56
Благодарности: 0

Профиль | Отправить PM | Цитировать


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

Отправлено: 08:48, 30-12-2004 | #13


Аватара для [mzd]

Линуксоид-стакановец


Сообщения: 2391
Благодарности: 186

Профиль | Отправить PM | Цитировать


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

-------
Живя в реальном мире, стремись к невероятному... Эрнесто Че Гевара
Everybody lies. (c) House M.D.
Базовая настройка Ubuntu. Документация для новичка.
Руководство по установке, начальной настройке и основам использования операционной системы Ubuntu


Отправлено: 19:27, 09-02-2005 | #14


Аватара для archy

Ветеран


Сообщения: 659
Благодарности: 3

Профиль | Отправить PM | Цитировать


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

Отправлено: 17:02, 11-02-2005 | #15

mar mar вне форума

Аватара для mar

just mar


Moderator


Сообщения: 3904
Благодарности: 163

Профиль | Отправить PM | Цитировать


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

Отправлено: 18:41, 11-02-2005 | #16


Новый участник


Сообщения: 7
Благодарности: 0

Профиль | Отправить PM | Цитировать


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

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

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

Отправлено: 22:59, 13-02-2005 | #17



Компьютерный форум OSzone.net » Linux и FreeBSD » Новости и флейм из мира *nix » Системы управления пакетами

Участник сейчас на форуме Участник сейчас на форуме Участник вне форума Участник вне форума Автор темы Автор темы Шапка темы Сообщение прикреплено

Похожие темы
Название темы Автор Информация о форуме Ответов Последнее сообщение
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




 
Переход