Некоторые пакеты, вне зависимости от их статуса, например, различные варианты сборки ядра, отмечены соответствующим значком (расшифровку его смысла см. на рис. 5). И для них не активизирован ни один пункт контекстного меню (или меню Пакет). Это так называемые исключения (EXCLUDE), о которых говорилось в главе шестой (и к которым мы ещё вернёмся в заключительном разделе):
Рисунок 7-11. Пакеты-исключения
Пакеты, входящие в список исключений, средствами Gslapt нельзя ни удалить, ни обновить, ни переустановить без некоторых дополнительных действий. Или это можно сделать из командной строки утилитой slapt-get с указанием опции --ignore-excludes.
Групповые действия с пакетами
Как помнится по главе пятой, утилита slapt-get может не только устанавливать, обновлять и удалять отдельные пакеты, но и обновлять систему в целом. Разумеется, на это способен и Gslapt: достаточно любым способом (горячими клавишами Control+A, через главное или контекстное меню) отметить все пакеты, для которых доступны обновления, после чего нажать Control+Enter или экранную кнопку Выполнить.
Система исключений, о которых говорилось ранее (см. главу шестую) и будет говориться ещё, практически гарантирует от неожиданностей, вроде внепланового обновления ядра. Однако не помешает внимательно посмотреть предлагаемый список пакетов, которые будут обновлены в результате этой операции:
Рисунок 7-12. Список пакетов, предназначенных к обновлению
Возможно, для каких-то из них пакетов списка обновление окажется нежелательным – например, для пакетов, пересобранных собственноручно. Правда, такие пакеты лучше заранее внести в список исключений: список обновляемых пакетов может быть или принят, или отвергнут целиком, коррекция его «по ходу дела» невозможна.
Правда, ничто не может помешать удалить из списка исключений тот или иной компонент – правда, я очень сомневаюсь в том, что это нужно делать. А вот возможность пополнить список – иногда может понадобиться, например, при наличии собственноручно модифицированных пакетов, которые следует сохранять при обновлении системы..
В Salix имеется и возможность автоматического отслеживания обновлений – она носит название Slapt-update-service, устанавливается и активизируется по умолчанию при первичной инсталляции системы. После чего представляет собой пиктограмму в системном лотке управляющей панели Xfce. О наличии обновлений сообщает всплывающая подсказка при наведении на неё курсора мыши. После чего щелчок мышью вызывает панель с предложением эти обновления выполнить:
Рисунок 7-13. Предложение автоматического обновления
Если согласиться с этим предложением – последует запрос пароля пользователя (см. рис. 7-1), после чего будет запущен Gslapt, который выведет список обновляемых пакетов, точно такой же, как на рис. 7-12. И к которому применимо всё, что было сказано относительно обновления непосредственно из Gslapt.
От автоматического отслеживания обновлений можно отказаться вообще: для этого достаточно исключить Slapt-update-service из списка системных служб. Как – будет рассказано в главе 10.
В общем обзоре Gslapt я упомянул о возможности отметить для удаления устаревшие пакеты. Вот здесь надо быть ещё более внимательным, чем при обновлении. Потому что в список устаревших пакетов попадут не только действительного таковые, но и, например, все пакеты, собранные из слакбилдов (о которых будет рассказано в следующей части). А вот их-то удалять совсем не стоит. Так что использовать отметку устаревших пакетов нужно только в информационных целях, а удалять их по одному вручную, дабы не потерять результаты труда по поиску нужных слакбилдов и их компиляции.
Я уже упоминал, что в Gslapt интегрирована настройка всей этой системы управления пакетами – та самая, которая в предыдущей главе выполнялась в «ручном режиме». Для чего в пункте Правка главного меню предусмотрен одноимённый подпункт, вызываемый также клавишной комбинацией Control+P.
Прежде чем переходить собственно к описанию настройки, подчеркну: Gslapt использует те же самые конфигурационные файлы и рабочие каталоги, что и slapt-get. Поэтому результаты «ручной» их правки, выполненной в текстовом редакторе, будут влиять на его работу. И наоборот: переопределение параметров конфигурирования, выполненное в графическом интерфейсе Gslapt, отразится на поведении консольного slapt-get. Именно поэтому, в частности, при совместном использовании обоих инструментов рекомендуется выполнять процедуру обновления локального кеша при каждом запуске того и другого.
А теперь собственно о конфигурировании в графическом интерфейсе. Вызываемая одним их упомянутых выше способов панель настройки содержит четыре вкладки. В первой можно переопределить рабочий каталог всей системы, в частности, локального кеша пакетов:
Рисунок 7-14. Определение рабочего каталога Gslapt
Чего, впрочем, без очень веских оснований делать не стоит – а оснований таких, как уже говорилось в предыдущей главе, я не вижу. А вот возможность очистить локальный кеш время от времени может оказаться востребованной – в частности, при смене версии дистрибутива.
Вкладка Исключения содержит список этих самых 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, служащей для работы со слакбилдами.
В самом общем виде слакбилд – это просто сценарий автоматической сборки любого бинарного пакета из его исходных текстов, обеспечивающий выполнение (почти) всех стадий этого процесса – получение «авторского» архива, его развёртывание в дерево исходников, их конфигурирование и собственно компиляцию, завершающуюся созданием бинарного пакета в формате Slackware. В идее слакбилдов легко увидеть черты сходства с портами FreeBSD, портежами Gentoo и особенно с Arch Building System дистрибутива Archlinux. Однако есть и несколько важных различий со всеми перечисленными системами пакетного менеджмента. О некоторых я скажу чуть позже.
Именно из слакбилдов собираются пакеты Slackware и всех её клонов, в том числе и Salix – те самые, которые лежат в соответствующих официальных репозиториях. Однако существует и огромное число пакетов, по тем или иным причинам не попавшим в состав «бинарного официоза» ни одного из дистрибутивов. Вот среди них и следует искать наши «недостачи».