Книга: Погружение в Salix

Управление пакетами: обзор

Управление пакетами: обзор

Впервой главе говорилось о сохранении совместимости Salix с оригинальной Slackware. Это касается и средств управления пакетами. Поэтому свой рассказ я начну с их обзора в прародительском дистрибутиве.

Сначала – несколько слов о формате пакетов. В Slackware и всех её клонах он предельно прост, представляя собой скомпилированные бинарные файлы «авторского» пакета (то есть созданного его разработчиком), собранные в архив утилитой tar, сжатый компрессором xz (современный суффикс файлов пакетов – txz). К этому добавляется описание пакета и, обычно, пред- и постинсталляционные сценарии. Однако никакой информации о зависимостях пакета в нём самом не содержится.

Базовые средства Slackware для работы с пакетами собраны в пакете (смайлики по вкусу) pkgtools. Он предназначен для работы с единичными пакетами или их сериями и объединяет следующие утилиты:

   • installpkg – установка пакета;

   • upgradepkg – обновление пакета;

   • removepkg – удаление пакета;

   • explodepkg – развёртывание пакета как архива;

   • makepkg – создание пакета.

Все они требуют указания аргумента в виде имени пакета (или группы пакетов, а первые три – ещё и прав администратора для своего выполнения.

Кроме того, имеется pkgtool — интегрирующая меню-ориентированная оболочка для установки, удаления и просмотра пакетов и их серий. Она имеет текстовый интерфейс на базе ncurces. Для запуска её обязательно требуются права суперпользователя

$ sudo pkgtool

В аргументах эта команда не нуждается, так как предполагает работу в интерактивном режиме.

Рисунок 5-1. Интерфейс утилиты pkgtool

Все утилиты работают напрямую с пакетами Slackware, которые, как уже сказано, информации о зависимостях не содержат. И потому они тоже никак зависимости не отслеживают – то есть не только не пытаются их разрешить, но даже не сообщают о нарушениях. То есть любой пакет будет установлен в любом случае, но если в системе отсутствуют пакеты, с которыми он связан жёсткими зависимостями (например, нужные для него библиотеки), то работать он просто откажется. Аналогично и с удалением пакетов: removepkg позволяет удалить библиотеки, от которых зависят другие пакеты системы – с вполне предсказуемым результатом.

Другая особенность инструментария pkgtools – его локальный характер, для работы с репозиториями он изначально не предназначался. Максимум, на что способны его утилиты – установление серий пакетов или пакетов из определённого каталога.

Казалось бы, по своим функциям инструменты pkgtools ничем не отличаются от связки обычного архиватора и декомпрессора сжатых файлов. Но это не так. Потому что они выполняют самую важную обязанность любого средства управления пакетами – их фиксацию в базе данных, что позволяет поддерживать систему в целостном состоянии, не превращая в свалку бинарников.

Отсутствие контроля зависимостей и средств работы с репозиториями – именно особенности инструментов pkgtools, а не их недостатки, потому что в ряде случаев могут оказаться и достоинствами. Впрочем, описание тех и других в мою задачу не входит. Важно, что утилиты pkgtools – это базовые средства для работы с пакетами в Slackware, и все остальные инструменты, о которых я скажу чуть позже, основываются на них. Поэтому они в обязательном порядке имеются во всех клона прародительской системы, в том числе и в Salix.

Кроме того, утилиты pkgtools имеют и самостоятельную ценность: часто они предоставляют простой способ установки и удаления единичных пакетов, не имеющих сложных зависимостей (или с зависимостями, хорошо известными применителю).

Тем не менее, с давних пор в Slackware разрабатываются различные надстройки над pkgtools, расширяющие возможности её утилит, с одной стороны, в плане работы с репозиториями, с другой – в отношении отслеживания зависимостей. Примером первых является пакет slackpkg, основное назначение которого – обеспечение доступа к официальному репозиторию Slackware (или одному из его зеркал) для установки и удаления пакетов, обновления системы и поддержания её целостности. Она, однако, также не предлагает никаких средств контроля зависимостей. Впрочем, в Salix по умолчанию slackpkg не устанавливается, и потому говорить о нём не будем.

Отсутствие в пакетах Slackware описания зависимостей отнюдь не мешает их контролю – напротив, облегчает его какими-либо внешними средствами – собственными, разработанными для этого дистрибутива (например, swaret) или заимствованными других систем пакетного менеджмента (ports, pkgsrc, packman и так далее). Большинство этих разработок не получили широкого распространения, некоторые вообще заброшены. Однако на долю одной из них выпал настоящий успех. Это – утилита slapt-get и её графический интерфейс Gslapt. Именно они по умолчанию применяются в Salix для управления пакетами.

Оглавление книги