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

Вкладка Исключения содержит список этих самых EXCLUDE, который по умолчанию выглядит так:

Рисунок 7-15. Список исключений

Ну а как с этим списком целесообразно обращаться – было сказано в главе шестой.

Вкладка Репозитории в наглядном виде воспроизводит соедержание третьей секции файла /etc/slapt-get/slapt-getrc:

Рисунок 7-16. Репозитории

Удалять здесь нечего, изменять – тоже, разве что задействовать другое зеркало. Что можно сделать также очевидным способом через добавление с последующим удалением старого:

Рисунок 7-17. Добавление репозитория

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

Наконец, последняя вкладка панели настроек – проверка GPG-ключей:

Рисунок 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, который, собственно, и является эпонимом этой системы. Он содержит огромную коллекцию тематически структурированных слакбилдов, сопровождающуюся средствами их поиска и инструкцией по применению.

Рисунок 8-1. Структура репозитория SlackBuilds.org

Обращение с найденным слакбилдом в общем случае примерно таково (хотя детали могут меняться). Вначале он (то есть файл вида *.SlackBuild и несколько файлов с метаинформацией, в том числе файлом README) скачивается в подходящий каталог, затем ему присваивается аттрибут исполнения:

$ chmod a+x *.SlackBuild

После чего эту способность к исполнению надлежит реализовать:

$ ./*.SlackBuild

Для обеих процедур, как можно видеть, достаточно прав обычного пользователя. В результате второй в текущем каталоге появляется скачанный из сети архив исходных текстов, файл проверки контрольной суммы, а в каталоге /tmp – готовый бинарный пакет, то есть файл вида *.txz. Который остаётся только установить обычным образом, например, описанным в главе пятой, разумеется, уже с правами администратора:

$ sudo installpkg *.txz