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

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

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

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

$ slapt-get [options] target [arguments]

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

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

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

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