Алексей Федорчук - Погружение в Salix

• Название: Погружение в Salix
• Автор: Алексей Федорчук
• Жанр: Программное обеспечение

Эта электронная книжка, aka e-book, посвящена дистрибутиву Salix – одному из «клонов» Slackware. Он интересен и сам по себе. Но также и тем, что среди всех потомков старейшего из выживших дистрибутивов он в наибольшей степени наследует особенности родительской системы. И потому знакомство с ним может рассматриваться (в том числе и) как самый быстрый и простой метод вхождения в мир Slackware. Ибо фраза «Если ты знаешь Slackware – ты знаешь Linux» до сих пор не потеряла своей актуальности.

Настоящая книжка не является руководством по Salix, Slackware или, тем более, по Linux'у вообще. Нет, это описание дистрибутив-специфических особенностей Salix'а – тех, которые показались мне интересными, и которые я задействовал в своей практической работе.

Основу книжки составили заметки о Salix на Блогосайте и цикл статей, размещённых на IBM developerWorks (содержание его здесь). Ныне они исправлены, дополнены и причёсаны, так что полного совпадения с материалами, ранее размещёнными на указанных ресурсах, нет.

Непосредственным стимулом к оформлению всех изложенных материалов послужило желание моего сына Виктора погрузиться в Salix самому и приобщить к нему сестру Ольгу. Так что им эта e-book'а и посвящается.

---

Отсутствие контроля зависимостей и средств работы с репозиториями – именно особенности инструментов 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