Погружение в Salix

В пятой главе сначала дан краткий обзор средства работы с пакетами, применяемыми в дистрибутивах семейства Slackware. Далее описывается утилита slapt-get – основной инструмент для работы с пакетами и репозиториями в дистрибутиве Salix: приведена общая её характеристика, специфические черты и примеры практического применения.

Введение

В Salix предусмотрено несколько средств для работы с пакетами,. С одной стороны, в нём имеются базовые утилиты, входящие в пакет pkgtools, унаследованный от Slackware. С другой – в нём могут быть установлены любые средства управления пакетами, когда-либо разрабатывавшиеся для родительского дистрибутива.

Но есть и третья сторона медали – принятые по умолчанию две пары инструментов управления пакетами и их репозиториями:

1. консольная утилита slapt-get и её графическая надстройка Gslapt, предназначенные для работы бинарными пакетами и их репозиториями; дополнительным средством к этой паре выступает служба slapt-update-service, отслеживающая изменения в репозиториях и запускающая по требованию программу Gslapt для обновления установленных пакетов;

2. также консольная программа slapt-src с графической оболочкой Sourcery – та и другая обеспечивают автоматизацию сборки пакетов из их исходных текстов с помощью специальных сценариев, так называемых слакбилдов (slackbuilds).

Три из этих четырёх инструментов, slapt-get, Gslapt и slapt-src не уникальны для Salix'а. Они были разработаны Язоном Вудвардом (Jason Woodward) для первозданной Slackware ещё в 2003-2005 годах, и с тех пор время от времени использовались как в ней самой, так и в ряде происходящих от неё дистрибутивов (например, в Vector Linux). Однако в состав официального дистрибутива она не была включена. Авторство же Sourcery принадлежит Жоржу Влахавасу — инициатору проекта Salix. И именно в этом дистрибутиве они были объединены «в одной коробке» и возведены в ранг основного инструментария для управления пакетами. Чем во многом и определилась специфика 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 для управления пакетами.

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

Впрочем, бывают и исключения. Например, консольные программы типа Midnight Commander или links собираются в Salix'е с поддержкой gpm – это необязательная («мягкая») зависимость, позволяющая использовать в них мышь как указательно-позиционирующее устройство.

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

Отличия утилиты slapt-get от прообраза проявляются и в её синтаксисе. Она требует обязательного указания так называемой цели (

target

$ slapt-get [options] target [arguments]

Обычно опции и цели представляют собой мнемонически прозрачные английские слова, предваряемые удвоенным символом дефиса. Например, цель --install указывает, что заданный в виде аргумента пакет должен быть установлен. В сопровождении же опции --reinstall она потребует переустановки уже имеющегося пакета другим экземпляром той же версии (например, если исходный экземпляр по каким-либо причинам был испорчен).

Некоторые опции и цели, кроме полной, многосимвольной, формы, имеют и форму краткую, односимвольную. В этом случае перед ними идёт одиночный дефис: так, цель -i является эквивалентом для --install.

Особую роль играет цель -h, или --help, служащая для вывода списка всех целей и опций. Впрочем, то же самое происходит, если дать команду slapt-get без указания опций, цели и аргументов, а также при ошибке в синтаксисе командной директивы.

Цели и опции в выводе -h сопровождаются описаниями – краткими, но кристально ясными, в локализованной системе во многих случаях (в частности, в нашем) – на родном языке применителя (то есть русском). Поэтому описывать их подробно я не буду. А остановлюсь на практическом применении утилиты slapt-get.

Утилита slapt-get: применение

Если в свежеустановленной системе Salix попытаться установить какой-либо пакет с помощью slapt-get, ответом будет такое сообщение:

$ sudo slapt-get --install zshЧтение списка пакетов...Не удалось открыть package_data package_data: Нет такого файла или каталога Возможно, вам нужна опция --update?

Это естественно: утилита slapt-get ничего не знает о содержимом репозитория, с которым она призвана работать. Чтобы она могла устанавливать из него пакеты и обновлять систему, она должна прочитать их список – файл PACKAGES.TXT, представляющий собой нечто вроде оглавления. Делается это командой

$ sudo slapt-get --update

И при первом запуске занимает некоторое время, зависящее от скорости соединения с сервером. И тут надо дать несколько пояснений. Во-первых, цель --update имеет и односимвольную форму -u.

Во-вторых, все цели команды slapt-get, связанные с установкой, обновлением или удалением пакетов, то есть изменениями в корневой файловой системе, требуют полномочий администратора – в дальнейшем такие команды будут указываться с предваряющей командой sudo. Очевидно, что цели, предоставляющие информацию о пакетах (о них скоро пойдёт речь), никаких действий не совершают, и потому для их исполнения достаточно прав обычного пользователя.

В-третьих, полное считывание файла происходит только при первом обращении к репозиторию: в дальнейшем проверяется только наличие в нём обновлений чтением файла ChangeLog.txt, что выполняется гораздо быстрее. Запускать же эту команду желательно перед установкой новых пакетов, обязательно – перед тотальным обновлением системы, и уж обязательно совсем – после любых изменений подключённых репозиториев, о чём будет говориться в главе шестой.

После формирования локального списка пакетов репозитория утилита slapt-get становится пригодной к установке или удалению программ, а также всех других действий, которые потребуются впредь. И первое из таких действий – это знакомство со списком пакетов, установленных в ходе первичной инсталляции системы. Делается это такой командой:

$ slapt-get --installed

Очевидно, что аргументов она не требует, а для её исполнения достаточно пользовательских полномочий. Именно таким способом (с перенаправлением по конвейеру на| w) определялось количество пакетов после разных вариантов установки (см. главу шестую).

Просмотр списка пакетов показывает, что некоторые из них – явно лишние (хотя, если честно, то это проще увидеть через главное меню Xfce). В частности, я первым делом удаляю браузер Midori, ибо назвать его вполне работоспособным в настоящее время трудно. Это требует определения точного имени соответствующего пакета:

$ slapt-get --search midori

Здесь аргумент уже требуется – это ключевое слово, котороеslapt-get будет искать в именах пакетов и их описаниях. И в результате выведет следующее:

midori-0.5.7-x86_64-1gv [inst=да]: midori (a lightweight web browser)

Можно видеть, что slapt-get, кроме имён пакета, полного и базового, а также его краткой характеристики, выводит и его статус (inst=[да/нет]): чтобы этому научиться, утилитам семейства APT, в лице только что появившегося apt, потребовалось 16 лет.

В полном имени пакет следует обратить внимание на символы после указания архитектуры – в данном случае 1gv: число указывает на номер его сборки, а литеры – сокращение от имени или ника майнтайнера. В примере они говорят, что таковым для Midori является Георгий Влахавас, и пакет этот собран специально для дистрибутива Salix, а не заимствован, скажем, из репозитория Slackware. Все расшифровки таких сокращений в обязательном порядке указаны для каждого участника проекта Salix. И скоро станет ясно, почему это имеет значение. А пока выполним собственно удаление пакета:

$ sudo slapt-get --remove midori

Если при установке пакетов slapt-get, с одной важной оговоркой, автоматически разрешает его зависимости, то при удалении попытки удалить их не делается, даже если они более никаким пакетом не используются. Так что единственный способ избавиться от таких «осиротелых» зависимостей – удалить их точно так же, как и сам пакет. А просмотреть список зависимостей можно такой командой:

$ apt-get --show midori

Вместе со всякого рода полезной информацией (приоритет, принадлежность к серии пакетов, размер файла пакета и его инсталляции) выведет и список зависимостей – правда, без всякой классификации на специфичные для пакета и общие. Так что удалять их следует с исключительной осторожностью, при полной уверенности в правильности своих действий. В частности, из зависимостей Midori все используются в других компонентах инсталляции BASIC, поэтому ни одной из них удалять нельзя – система будет просто неработоспособной.

В результате удаления Midori наша инсталляция Salix остаётся без браузера вообще, в чём легко убедиться такой командой:

$ apt-get --search browser | grep inst=да

Передача по конвейеру результатов вывода «информационных» целей slapt-get очень полезна при отборе необходимых пакетов. Особенно эффективно этот механизм работает в командной оболочке zsh, в которой для командных конструкций конвейеризации предусмотрены так называемые глобальные псевдонимы. В частности в конфигурационном файле ~/.zshrc можно задать строку вида

alias -g G='|grep'

и после этого использовать для фильтрации пакетов директиву вида

$ apt-get --search browser G inst=да

Впрочем, преимущества zsh этим не ограничиваются, почему я много лет применяю его в качестве пользовательской командной оболочки по умолчанию. Но это тема другого разговора.

Так что надо срочно устанавливать ему замену – например, Firefox; не потому, что он лучше всех – но для некоторых моих задач альтернативы не имеется. Как и раньше, определяем точное имя пакета – и сталкиваемся с неожиданностью – в выводе команды

$ slapt-get --search firefox

обнаруживается два подходящих пакета:

mozilla-firefox-24.1.0esr-x86_64-1 [inst=нет]: mozilla-firefox(Mozilla Firefox Web browser) mozilla-firefox-24.5.0esr-x86_64-1gv [inst=нет]: mozilla-firefox (safe and easy web browser from Mozilla)

Тут-то и впору вспомнить о суффиксах после номера сборки пакета: одна сборка принадлежит проекту Salix, вторая – взята из репозитория Slackware. Правда, в данном случае ломать голову особенно не приходится: команда

$ sudo slapt-get --install mozilla-firefox

по умолчанию установит «родную» сборку пакета, скачав её с соответствующей ветви репозитория, что сейчас и требуется. Но возможны ситуации, когда выбор между сборками придётся делать применителю.

Полный список файлов, которые добавляются в систему при установке пакета, вместе с путями к ним в дереве файловой системы, можно получить, используя цель --filelist. Например, для firefox команда:

$ slapt-get --filelist mozilla-firefox

выведет длинный список, начинающийся так:

/usr/ /usr/bin/ /usr/doc/ /usr/doc/mozilla-firefox-24.5.0esr/ /usr/lib64/ /usr/lib64/firefox-24esr/

Цель

--filelist

Отдельной цели для обновления единичного пакета до его более свежей версии в slapt-get не предусмотрено. Это достигается с помощью всё той же цели

--install

Ранее я упоминал опцию

--reinstall

$ sudo slapt-get --install --reinstall joe

Кроме того, все пакеты, установленные в системе, для которых доступны новые версии, можно обновить «гуртом» такой командой:

$ sudo slapt-get --upgrade

Важно, что общее обновление системы не затрагивает пакеты, внесённые в список так называемых исключений (excludes) – в их число входит, в частности, ядро системы, библиотеки поддержки формата ELF и некоторые другие компоненты, смена версий которых не всегда желательна. Правда, может обновить и их, однако для этого применителю потребуется задать опцию --ignore-excludes, что снижает вероятность, например, ошибки при загрузке вследствие несоответствия текущей версии ядра и той, что прописана в конфигурационном файле LILO.

Наконец, при выходе новой версии дистрибутива вовсе не обязательно заниматься переустановкой её «с нуля» – достаточно выполнить команду

$ sudo slapt-get --dist-upgrade

которая проделает эту работу автоматически.

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

--prompt

-p

-y

И ещё одна важная опция для применителя, впервые сталкивающегося с утилитой slapt-get: -s, или --simulate. Как явствует из её имени, она имитирует выполнение установки, удаления или обновления пакетов, выводя сообщение об их результате, но не выполняет никаких действий. Так что в сомнительных случаях можно обратиться к ней.

Пара слов в заключение

Утилита slapt-get предусматривает ещё несколько целей (таких, как --clean – очистка локального кеша пакетов, или --autoclean – удаление пакетов устаревших). Есть в ней и ещё немного сопровождающих опций (например, --download-only – скачивание пакетов без их установки, что может быть полезным при переносе на машину, не имеющую подключения к Интернету). Однако я и не ставил своей целью написать полное руководство по slapt-get, тем более что таковое, в виде одноимённой man-страницы, давно написано. Тем не менее, сказанного, думаю, достаточно, чтобы сделать два вывода.

Вывод первый: не смотря на свою простоту и внешнюю непритязательность, утилита slapt-get справляется с задачами управления пакетами ничуть не хуже, чем утилиты семейства APT, косвенно послужившие её прообразом.

Вывод второй: своему успешному применению утилита slapt-get обязана не только своим достоинствам, но и репозиториям, специально подготовленным для работы с ней. Устройство репозиториев – очередная специфическая особенность дистрибутива Salix, которая будет рассмотрена в следующей главе.