Погружение в Salix
Шрифт:
2. также консольная программа slapt-src с графической оболочкой Sourcery – та и другая обеспечивают автоматизацию сборки пакетов из их исходных текстов с помощью специальных сценариев, так называемых слакбилдов (slackbuilds).
Три из этих четырёх инструментов, slapt-get, Gslapt и slapt-src не уникальны для Salix'а. Они были разработаны Язоном Вудвардом (Jason Woodward) для первозданной Slackware ещё в 2003-2005 годах, и с тех пор время от времени использовались как в ней самой, так и в ряде происходящих от неё дистрибутивов (например, в Vector Linux). Однако в состав официального дистрибутива она не была включена. Авторство же Sourcery принадлежит Жоржу Влахавасу — инициатору проекта 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 разрабатываются различные надстройки над pkgtools, расширяющие возможности её утилит, с одной стороны, в плане работы с репозиториями, с другой – в отношении отслеживания зависимостей. Примером первых является пакет slackpkg, основное назначение которого – обеспечение доступа к официальному репозиторию Slackware (или одному из его зеркал) для установки и удаления пакетов, обновления системы и поддержания её целостности. Она, однако, также не предлагает никаких средств контроля зависимостей. Впрочем, в Salix по умолчанию slackpkg не устанавливается, и потому говорить о нём не будем.
Отсутствие в пакетах Slackware описания зависимостей отнюдь не мешает их контролю – напротив, облегчает его какими-либо внешними средствами – собственными, разработанными для этого дистрибутива (например, swaret) или заимствованными других систем пакетного менеджмента (ports, pkgsrc, packman и так далее). Большинство этих разработок не получили широкого распространения, некоторые вообще заброшены. Однако на долю одной из них выпал настоящий успех. Это – утилита slapt-get и её графический интерфейс Gslapt. Именно они по умолчанию применяются в Salix для управления пакетами.
Утилита slapt-get: обзор
Утилита slapt-get, предназначенная в Salix для манипуляции пакетами и их репозиториями, создавалась во многом «по мотивами» семейства утилит APT из дистрибутива Debian. Однако это не адаптация последних для пакетов иного формата, подобно apt-rpm. Скорее, она объединяет большую часть функциональности утилит apt-get и apt-cache своими собственными средствами.
В отличие от базовых средств pkgtools, утилита slapt-get работает не с отдельными пакетами, а с их репозиториями, сетевыми или локальным. Одно из зеркал официального репозитория проекта Salix мы выбирали на стадии инсталляции системы (см. главу вторую). При этом slapt-get, подобно утилитам семейства APT, не просто устанавливает пакеты и регистрирует их в базе данных, но и контролирует зависимости (с некоторыми оговорками, о которых я скажу позднее). Однако делается это иначе, чем в apt-get.
В пакетах формата deb зависимости прописаны внутри файла пакета, причём устанавливается довольно сложная их иерархия – обязательные, рекомендованные, предлагаемые, конфликтующие. А apt-get разрешает их в соответствии с метаинформацией пакета и собственными настройками, определяющими правила обращения с зависимостями необязательными (обязательные зависимости устанавливаются в любом случае).
Формат пакетов Slackware, как уже говорилось, не предусматривает информации о зависимостях: эта функция, если она поддерживается, возлагается внешние их описания. Например, в официальном репозитории Salix зависимости пакета фиксируются в одноимённом ему файле с суффиксом dep. Это – простой текстовый файл, в котором перечислены пакеты, от которых зависит данный. При этом никаких градаций зависимостей по их «важности», как в deb-формате, нет: все они обязательны к разрешению. Однако пакеты Salix, как и Slackware, традиционно собираются по возможности с включением только обязательных (так называемых «жёстких») зависимостей. За счёт чего, кстати, и достигается компактность инсталляции этого дистрибутива, о которой шла речь в главе четвёртой.