$ 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, которая вместе с целью -i заменяет, при необходимости, установленный пакет другим его экземпляром той же версии:
$ sudo slapt-get --install --reinstall joe
Кроме того, все пакеты, установленные в системе, для которых доступны новые версии, можно обновить «гуртом» такой командой:
$ sudo slapt-get --upgrade
Важно, что общее обновление системы не затрагивает пакеты, внесённые в список так называемых исключений (excludes) – в их число входит, в частности, ядро системы, библиотеки поддержки формата ELF и некоторые другие компоненты, смена версий которых не всегда желательна. Правда, может обновить и их, однако для этого применителю потребуется задать опцию --ignore-excludes, что снижает вероятность, например, ошибки при загрузке вследствие несоответствия текущей версии ядра и той, что прописана в конфигурационном файле LILO.
Наконец, при выходе новой версии дистрибутива вовсе не обязательно заниматься переустановкой её «с нуля» – достаточно выполнить команду
$ sudo slapt-get --dist-upgrade
которая проделает эту работу автоматически.
Важно, что при установке пакета подтверждение на выполнение действий по умолчанию не запрашивается, а при удалении (и при тотальном апгрейде), напротив, требуется. Это положение можно изменить, указав в первом случае опцию --prompt (она же -p), во втором --no-prompt (или -y).
И ещё одна важная опция для применителя, впервые сталкивающегося с утилитой slapt-get: -s, или --simulate. Как явствует из её имени, она имитирует выполнение установки, удаления или обновления пакетов, выводя сообщение об их результате, но не выполняет никаких действий. Так что в сомнительных случаях можно обратиться к ней.
Утилита slapt-get предусматривает ещё несколько целей (таких, как --clean – очистка локального кеша пакетов, или --autoclean – удаление пакетов устаревших). Есть в ней и ещё немного сопровождающих опций (например, --download-only – скачивание пакетов без их установки, что может быть полезным при переносе на машину, не имеющую подключения к Интернету). Однако я и не ставил своей целью написать полное руководство по slapt-get, тем более что таковое, в виде одноимённой man-страницы, давно написано. Тем не менее, сказанного, думаю, достаточно, чтобы сделать два вывода.
Вывод первый: не смотря на свою простоту и внешнюю непритязательность, утилита slapt-get справляется с задачами управления пакетами ничуть не хуже, чем утилиты семейства APT, косвенно послужившие её прообразом.
Вывод второй: своему успешному применению утилита slapt-get обязана не только своим достоинствам, но и репозиториям, специально подготовленным для работы с ней. Устройство репозиториев – очередная специфическая особенность дистрибутива Salix, которая будет рассмотрена в следующей главе.
Глава 6. Управление пакетами: репозитории
В шестой главе рассказывается о сериях пакетов Slackware и их назначении, об устройстве репозиториев Salix и их отличиях от репозиториев прародительской системы, в частности – о способах, обеспечивающих в них контроль зависимостей. После этого рассматривается настройка утилиты slapt-get, и дан обзор зеркал репозиториев Salix, а также неофициальных репозиториев Slackware, которые также могут быть использованы в этом дистрибутиве.
Серии пакетов Slackware: вместо введения
Прежде чем перейти к описанию устройства репозиториев Salix, необходимо сказать несколько слов о существующим в Slackware и её клонах понятии серий пакетов.
Во всех развитых системах пакетного менеджмента существует понятие так называемых метапакетов (metapackages), хотя они носят разные имена, Во FreeBSD, из которой и пошло это понятие, они называются метапакетами и метапортами, в дистрибутивах, использующих формат пакетов deb – задачами (tasks), в openSUSE – шаблонами (patterns), в Fedora – группами (groups). Однако суть остаётся одна и та же. Метапакет – это список тем или иным образом связанных пакетов, которые могут быть установлены, обновлены и, в некоторых случаях, удалены одной командой.
В Slackware и её клонах (в том числе и в Salix) аналогом метапакетов являются серии или наборы пакетов (series или sets). Классический список таких серий, сформированный в незапамятные времена зарождения прародительской системы, включает следующие компоненты:
• a – минимальный набор пакетов для функционирования системы в консольном режиме;
