Средства установки пакетов

Среди средств установки пакетов первым надо назвать их компиляцию из исходных текстов, как наиболее универсальное и лежащее в первооснове всего — ведь любые бинарники в самом изощренном формате, управляемые самыми хитрыми менеджерами пакетов, некогда были собраны из исходников посредством трех волшебных заклинаний:

$ ./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 относятся к теме шелла и утилит, в каковой рубрике и будут рассмотрены.

Далее следуют дистрибутив-специфичные утилиты установки пакетов. Типичным примером таковых можно считать installpkg сотоварищи из Slackware. Это средство установки пакетов в чистом виде: запущенное командой вида

$ installpkg path2/pkg_name-##version.tgz

(с указанием полного пути к тарбаллу и полного его имени) оно всего-то и делает, что разворачивает тарбалл, запускает прединсталляционный скрипт, «размазывает» извлечённые из архива компоненты по файловому древу, после чего запускает еще один скрипт, уже постинсталляционный.

Ни малейшего контроля зависимостей при этом не происходит. Если зависимости удовлетворены — пакет запустится и будет нормально работать. Если не удовлетворены «жесткие» зависимости — пакет благополучно установится, без всяких сообщений об ошибках (да и откуда им взяться — ведь никакой метаинформации внутри него нет), но работать не будет. При нарушении зависимостей мягких пакет будет работать с «обрезанной» функциональностью (хотя, возможно, это именно то, что нужно пользователю).

Следующий шаг в направлении систем управления пакетами являют собой утилиты pkg_add из Free-, Net- и DragonFlyBSD (поминаю, что в первой системе и в двух последующих это две разные программы). В локальном режиме они работают почти также, как их родственник из Slackware, то есть требуют в качестве аргумента полного пути к имени файла, которое также должно указываться в полном виде. Контроля зависимостей при этом также не осуществляется. Однако, поскольку информация о зависимостях описана в тарбаллах, при их нарушении установки не происходит, а выдается сообщение об ошибке, сопровождаемое списком недостающих пакетов.

Однако в сетевом режиме, при определении соответствующей переменной, указывающей URL репозитория, команда в форме

$ pkg_add -r pkg_basename

установит как сам пакет, так и все его зависимости.

Некоторый контроль зависимостей обеспечивают также низкоуровневые утилиты rpm и dpkg (для пакетов rpm- и deb-формата, соответственно). Правда, сами по себе зависимостей они не разрешают, а лишь сообщают об их нарушении, причём в различной форме: dpkg при этом выводит список отсутствующих пакетов, а rpm -- список конкретных, например, библиотечных, файлов. Принадлежность которых к определённым пакетам ещё надо определить специальными средствами -- об этом будет говориться на страницах, посвящённых rpm-пакетам вообще.

Утилиты типа pkg_add из BSD-систем и близкие им по функциональности утилиты установки из Linux-дистрибутивов перекидывают мостик между средствами установки пакетов и системами пакетного менеджмента.


Теги: , , , , , ,