архив
Zenwalk
Приобщение к Linux
2008-06-25
Средства установки пакетов
Среди средств установки пакетов первым надо назвать их компиляцию из исходных текстов, как наиболее универсальное и лежащее в первооснове всего — ведь любые бинарники в самом изощренном формате, управляемые самыми хитрыми менеджерами пакетов, некогда были собраны из исходников посредством трех волшебных заклинаний:
$ ./configure && make && make install
Контроль зависимостей, если это можно назвать столь громким словом, осуществляется на стадии начального конфигурирования. Конфигурационный сценарий configure, обычно входящий в состав авторского пакета, просматривает дерево файловой иерархии целевой системы на предмет компонентов, необходимых для установки и работы пакета, и если всё, что нужно, в системе находится, создает Make-файл с описанием необходимых параметров.
Если же чего-то из необходимого в системе не находится — следует сообщение об ошибке, информативность которого зависит от старательности разработчика.
При благоприятном завершении начального конфигурирования запускается утилита make, которая производит компиляцию исполняемого файла (файлов) пакета и его линковку, то есть связывание с библиотечными функциями. Наконец, команда make install раскидывает скомпилированные компоненты и сопутствующие файлы по нужным ветвям файлового дерева системы.
Следующее столь же универсальное средство установки единичного пакета — банальные декомпрессия бинарного архива и его развертывание в предусмотренном для этого каталоге. Этот способ довольно часто применяется для коммерческих программ, распространяемых только в бинарном виде. Таким же образом устанавливается, например, OpenOffice.org из сборки проекта Инфра-Ресурс под абстрактный Linux, которая и представляет собой обычный файл *.tar.gz. Вся процедура сводится к одной из директив
$ tar zxvf pkg_name
если архив компрессирован утилитой gzip, или
$ tar jxvf pkg_name
если использовалось сжатие утилитой bzip2. Детали работы архиватора tar и компрессоров gzip и bzip2 относятся к теме шелла и утилит.
Далее следуют утилиты семейства pkg_add сотоварищи, иногда объединяемые в семейство pkgtool. Как я уже говорил, под этим именем укрываются весьма разные программы. Так, pkg_add из старых версий Slackware — (ныне в ней используется installpkg) это средство установки пакетов в чистом виде: запущенное командой вида
$ pkg_add path2/pkg_name-##version.tgz
(с указанием полного пути к тарбаллу и полного его имени) оно всего-то и делает, что разворачивает тарбалл, запускает прединсталляционный скрипт, «размазывает» извлечённые из архива компоненты по файловому древу, после чего запускает еще один скрипт, уже постинсталляционный.
Ни малейшего контроля зависимостей при этом не происходит. Если зависимости удовлетворены — пакет запустится и будет нормально работать. Если не удовлетворены «жесткие» зависимости — пакет благополучно установится, без всяких сообщений об ошибках (да и откуда им взяться — ведь никакой метаинформации внутри него нет), но работать не будет. При нарушении зависимостей мягких пакет будет работать с «обрезанной» функциональностью (хотя, возможно, это именно то, что нужно пользователю).
Следующий шаг в направлении систем управления пакетами являют собой утилиты pkg_add из Free-, Net- и DragonFlyBSD (поминаю, что в первой системе и в двух последующих это две разные программы). В локальном режиме они работают почти также, как их тёзка из Slackware, то есть требуют в качестве аргумента полного пути к имени файла, которое также должно указываться в полном виде. Контроля зависимостей при этом также не осуществляется. Однако, поскольку информация о зависимостях описана в тарбаллах, при их нарушении установки не происходит, а выдается сообщение об ошибке, сопровождаемое списком недостающих пакетов.
Однако в сетевом режиме, при определении соответствующей переменной, указывающей URL репозитория, команда в форме
$ pkg_add -r pkg_basename
установит как сам пакет, так и все его зависимости.
Утилиты типа pkg_add из BSD-систем перекидывают мостик между средствами установки пакетов и системами, обеспечивающими
Пакетный менеджмент
Системы управления пакетами представляют собой надстройки над низкоуровневыми средствами управления пакетами. От последних их отличают две особенности: отслеживание зависимостей при установке и занесение инсталлированных пакетов в специальные базы данных, обеспечивающие учет и контроль не только при установках последующих пакетов, но и при их удалении.
Из систем пакетного менеджмента наиболее известны и распространены семейство утилит apt, особенно механизм apt-get. Появившийся сначала в Debian'е и рассчитанный, соответственно, на deb-пакеты, он очень быстро стал универсальным кросс-пакетным механизмом установки, удаления и обновления программ, успешно работая с пакетами rpm (дистрибутивы Connectiva, Altlinux), тарбаллами Slackware (механизм slapt-get). И в принципе не видно препятствий к прикручиванию его к тарбаллам любого формата - от «чистых» до сколь угодно насыщенных метаинформацией.
Кроме собственно apt, в Debian'е и его клонах используется родственная система пакетного менеджмента - aptitude, а также ряд графических фронт-эндов (Synaptic, Adept). Правда, не знаю, насколько они получили распространение за пределами родительского семейства.
Под явным влиянием apt возникли и иные системы пакетного менеджмента - yum, urpmi и так далее. Однако они ориентированы только на rpm-пакеты (вероятно, их можно использовать и для иных форматов, но кому это нужно при наличии apt?) и потому не получили столь широкого распространения, оставаясь принадлежностью «родительских» дистрибутивов и более-менее точных их клонов. Так, yum, насколько мне известно, используется только в RHEL/Fedora и ASPlinux, urpmi — только в Mandriva.
При всех немерянных достоинствах apt-семейства, у его представителей есть особенность, которая некоторыми может восприниматься как недостаток. Это, во-первых, обилие отдельных утилит в семействе, во вторых, изобилие опций у каждой из них. И потому по образу и подобию apt было создано несколько систем пакетного менеджмента, более простых в изучении и обращении, но, соответственно, обладающих и меньшими возможностями.
Наибольшую известность из таких «облегчённых» систем управления пакетами получил pacman, разработанный для Archlinux, но, как уже говорилось, «прикрученный» и к чистым тарбаллам Slackware (пакеты самого Archlinux'а информацию о зависимостях содержат примерно в том же виде, что и в пакетах FreeBSD).
К слову говоря, пакеты Archlinux, являют собой пример эффективного контроля зависимостей за счет внешних баз данных - базы пакетного репозитория (на установочном диске и на сервере проекта) и базы пакетов, установленных на локальной машине. Гибкость такого «внешнего» метода пакетного менеджмента определяется тем, что пользователь может легко создать собственный пакетный репозиторий в базой данных, в которой описаны только нужные ему зависимости.
Другим, еще более простым, пакетным менеджером, ориентированным как раз на «чистые» тарбаллы, стала утилита netpkg, разработанная в рамках проекта Zenwalk и пока еще никуда не прикрученная.
Следует отметить, что собственно для Slackware была создана и собственная утилита установки, обеспечивающая отслеживание зависимостей — swaret, но в штатный комплект этого дистрибутива она так и не включена.
Системы построения пакетов
Системы построения пакетов автоматизируют процесс их сборки из исходников. Они представляют собой набор правил, обеспечивающих получение исходных текстов из Сети, их распаковку, компиляцию, сборку готового бинарного пакета, который устанавливается либо непосрдественно, либо обычными средствами пакетного менеджмента.
Прародителем всех систем построения пакетов была система портов FreeBSD, практически в неизменном виде заимствованная OpenBSD и некоторое время использовавшаяся по наследству в DragonFlyBSD. Под ее влиянием возникла очень сходная система pkgsrc в NetBSD, о которой уже была речь.
Однако разработчики дистрибутивов Linux, как правило, идут своим путем в деле создания систем портирования. Правда, такие их представители, как CRUX и Archlinux, не очень далеко отошли от прототипа. В них портообразные системы построения пакетов (ports и ABS, соответственно) мирно сосуществуют с самостоятельными (и весьма развитыми) средствами пакетного менеджмента: так, pacman из Archlinux, если еще и не достиг мощи Debian'овского apt'а, то стремительно движется в этом направлении. Тем не менее, сами пакеты, распространяемые в составе дистрибутива, генерируются за счет портообразной системы, которая позволяет также легко выполнить и пересборку базовой системы в соответствие с запросами пользователя.
Самой известной, распространенной и, я бы сказал, самой изощренной портообразной системой Linux-мира являются портэжи (portages) из дистрибутива Gentoo, меньшей популярностью пользуются sorcery, применяемый в дистрибутивах Sorcerer и SourceMage, и его потомок lunar из одноименного дистрибутива. Не смотря на их принципиальное сходство (обусловленное наследованием идейных традиций портов FreeBSD), двух одинаковых среди них мы не обнаружим - система portage из Gentoo отличается от «заклинаний» (sorcery) из Sorcerer как реализацией, так и приемами использования.
Непреодолимой грани между системами управления бинарными пакетами и производными от системы портов не существовало никогда, а со временем она всё больше стирается. Так, Debian'овская утилита apt-build позволяет одной директивой пересобрать «с нуля» всю систему ничуть не менее эффективно, нежели это делает emerge из дистрибутива Gentoo. Для которого, кстати, существует несколько вариантов распространения в бинарной форме. Бинарные пакеты FreeBSD, NetBSD и DragonFlyBSD генерируются из исходников посредством системы портов или pkgsrc, соответственно. А для Archlinux и особенно CRUX вообще трудно сказать, где кончаются порты и начинаются бинарники.
С другой стороны, некоторые системы пакетного менеджмента (например, netpkg и swaret) не сопряжены с системами построения пакетов и не являются их производными. Хотя средства автоматизированной сборки пакетов существуют и для них (иначе им нечем было бы управлять), они не пронизывают всю систему сверху донизу, как это характерно для Gentoo и, в меньшей степени, остальных портообразных систем.
Могу предположить, что и для rpm-based дистрибутивов существуют средства автоматической сборки системы из исходников, посредством которых собираются, вероятно, такие клоны RHEL (Red Hat Enterprise Linux), как Scientific Linux и CentOS. Однако и они не валяются навиду, не являясь сквозными для этих дистрибутивов. Хотя, возможно, что я просто недостаточно осведомлен в этой области.
Что же до Debian, то в нем скорее не пакетный менеджмент является производным системы построения пакетов, а как раз наоборот: механизм apt-build являет собой лишь частный случай использования метамеханизма, если так можно выразиться, apt. Показательно, что родственные apt системы или производные от нее (aptitude и synaptic, соответственно) аналогов механизма apt-build вроде бы не имеют. И, кстати, мне не доводилось слышать, чтобы кто-нибудь из лично знакомых пользователей Debian'а или убунтоидов еженедельно занимался пересборкой системы посредством
$ apt-build world
А ведь это занятие занимает не последнее место в распорядке дня каждого истинного джентушника...
В общем, можно констатировать, что большинство распространённых дистрибутивов Linux и, несколько в меньшей степени, BSD-систем и систем, основанных на OpenSolaris, допускают более или менее широкий выбор средств установки пакетов, систем управления бинарными пакетами и (или) портообразных систем. И каждый из доступных вариантов имеет свое целевое назначение.
Давно прошли времена, когда казалось, что сборка системы «с нуля», использующая должные флаги оптимизации для наличного «железа» — идея, наиболее последовательно проводимая в Gentoo, — способна обеспечить фантастический прирост производительности по известному принципу «счастье для всех — и даром». И потому разумным решением будет сочетание пакетной установки (оптимальной в большинстве случаев) и собственной сборки критически важных приложений.