Погружение в Salix
Шрифт:
В общем обзоре Gslapt я упомянул о возможности отметить для удаления устаревшие пакеты. Вот здесь надо быть ещё более внимательным, чем при обновлении. Потому что в список устаревших пакетов попадут не только действительного таковые, но и, например, все пакеты, собранные из слакбилдов (о которых будет рассказано в следующей части). А вот их-то удалять совсем не стоит. Так что использовать отметку устаревших пакетов нужно только в информационных целях, а удалять их по одному вручную, дабы не потерять результаты труда по поиску нужных слакбилдов и их компиляции.
Настройка Gslapt
Я уже упоминал,
Прежде чем переходить собственно к описанию настройки, подчеркну: Gslapt использует те же самые конфигурационные файлы и рабочие каталоги, что и slapt-get. Поэтому результаты «ручной» их правки, выполненной в текстовом редакторе, будут влиять на его работу. И наоборот: переопределение параметров конфигурирования, выполненное в графическом интерфейсе Gslapt, отразится на поведении консольного slapt-get. Именно поэтому, в частности, при совместном использовании обоих инструментов рекомендуется выполнять процедуру обновления локального кеша при каждом запуске того и другого.
А теперь собственно о конфигурировании в графическом интерфейсе. Вызываемая одним их упомянутых выше способов панель настройки содержит четыре вкладки. В первой можно переопределить рабочий каталог всей системы, в частности, локального кеша пакетов:
Рисунок 7-14. Определение рабочего каталога Gslapt
Чего, впрочем, без очень веских оснований делать не стоит – а оснований таких, как уже говорилось в предыдущей главе, я не вижу. А вот возможность очистить локальный кеш время от времени может оказаться востребованной – в частности, при смене версии дистрибутива.
Вкладка Исключения содержит список этих самых EXCLUDE, который по умолчанию выглядит так:
Рисунок 7-15. Список исключений
Ну а как с этим списком целесообразно обращаться – было сказано в главе шестой.
Вкладка Репозитории в наглядном виде воспроизводит соедержание третьей секции файла /etc/slapt-get/slapt-getrc:
Рисунок 7-16. Репозитории
Удалять здесь нечего, изменять – тоже, разве что задействовать другое зеркало. Что можно сделать также очевидным способом через добавление с последующим удалением старого:
Рисунок 7-17. Добавление репозитория
А к подключению сторонних репозиториев, не относящихся к проекту Salix, следует относиться с осторожностью – впрочем, об этом уже было сказано в предыдущей части.
Наконец, последняя вкладка
Рисунок 7-18. Проверка GPG-ключей
Это – разовая операция, и для подключенных при установке репозиториев она была выполнена. Так что обращаться к этой вкладке придётся только в случае подключения репозитория нового. При этом надо учитывать, что некоторые репозитории, приведённые в списке, GPG-ключей не содержат. Это не препятствует их использованию в Salix'е, но вызывает соответствующие сообщения, могущие смутить умы.
Краткий итог
Можно видеть, что Gslapt по своему функционалу, как и следовало ожидать, полностью повторяет консольную утилиту slapt-get (ибо является надстройкой над ней). И при этом включает в себя функции настройки, которая иначе реализуется прямым редактированием конфигурационных файлов, и проверки обновлений, которая в slapt-get не предусмотрена. Кроме того, все возможности по работе с пакетами в Gslapt предстают в очень наглядной форме.
Тем не менее, Gslapt не столько заменяет, сколько дополняет консольное средство:slapt-get быстрее и проще в использовании. Кроме того, все действия по получению информации о пакетах в нём могут быть выполнены с правами обычного пользователя.
Так что краткий итог моего затянувшегося обзора таков: slapt-get и Gslapt целесообразно применять параллельно, по ситуации. Нужно только помнить о взаимовлиянии их настроек и всегда начинать работу с ними с обновления локального кеша.
Глава 8. Управление пакетами: сборка из исходных текстов
В восьмой главе рассказывается о сборке пакетов из исходных текстов и о специально предназначенном для этого механизме Slackbuilds, о репозиториях слакбилдов вообще и официальных репозиториях слакбилдов для Salix в частности, а также об утилите slapt-src, служащей для работы со слакбилдами.
Что такое slackbuilds
В самом общем виде слакбилд – это просто сценарий автоматической сборки любого бинарного пакета из его исходных текстов, обеспечивающий выполнение (почти) всех стадий этого процесса – получение «авторского» архива, его развёртывание в дерево исходников, их конфигурирование и собственно компиляцию, завершающуюся созданием бинарного пакета в формате Slackware. В идее слакбилдов легко увидеть черты сходства с портами FreeBSD, портежами Gentoo и особенно с Arch Building System дистрибутива Archlinux. Однако есть и несколько важных различий со всеми перечисленными системами пакетного менеджмента. О некоторых я скажу чуть позже.
Именно из слакбилдов собираются пакеты Slackware и всех её клонов, в том числе и Salix – те самые, которые лежат в соответствующих официальных репозиториях. Однако существует и огромное число пакетов, по тем или иным причинам не попавшим в состав «бинарного официоза» ни одного из дистрибутивов. Вот среди них и следует искать наши «недостачи».
И первым шагом на этом пути будет посещение сайта SlackBuilds.org, который, собственно, и является эпонимом этой системы. Он содержит огромную коллекцию тематически структурированных слакбилдов, сопровождающуюся средствами их поиска и инструкцией по применению.