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

Таблица 6-1. Время отклика зеркал официального репозитория Salix

Примечание: сервера в таблице приведены в порядке возрастания времени отклика; н./с. – нет соединения.

Разумеется, данные в таблице приведены только для общей ориентировки – они зависят от многих факторов, и у читателя могут быть другими. Однако в целом можно констатировать, что для России все «заокеанские» сервера, включая и предлагаемый по умолчанию, – не лучший выбор. Я обычно выбираю Нидерландский или Бельгийский серверы – в условиях Москвы они хорошо показывают себя и для зеркал многих других дистрибутивов.

Количество пакетов в репозитории Salix по определению ограниченно – разработчики этого дистрибутива принципиально не стремились объять необъятный мир свободного программного обеспечения. Поэтому вполне реальна ситуация, когда применитель не обнаружит жизненно важного или любимого пакета. И тут восполнить «недостачу» можно двумя способами.

Один из них – сборка недостающих пакетов из исходных текстов. Разумеется, не в «лобовом» варианте, с помощью трёх волшебных заклинаний./configure, make, make install: этот путь очень быстро приведёт к захламлению системы, и прибегать к нему следует в самом крайнем случае. Да в нём нет и необходимости: от Slackware дистрибутив Salix унаследовал механизм работы с так называемыми слакбилдами (Slackbuilds) – сценариями автоматизированной сборки пакетов. И, более того, укрепил и расширил их, в том числе с помощью графической оболочки к консольным средствам. Но этот путь будет рассмотрен в одной из ближайших частей.

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

Неофициальные репозитории Slackware – это своего рода налоги PPA-репозиториев Ubuntu или «домашних» репозиториев openSUSE. Они не столь многочисленны, как последние (и, тем более, первые). Но имеют место быть, причём некоторые из них развиваются уже многие годы, возникнув задолго до создания PPA и OBS. Среди них можно видеть

• репозитории «братских» дистрибутивов, подобно Salix, сохраняющих полную совместимость со Slackware (например, репозиторий дистрибутива Slackel;

• репозитории для сборки специализированнх систем – примером может послужить Microlinux Enterprise Desktop(или просто MLED);

• хранилища пакетов для отдельных интегрированных сред (например, Ktown, содержащий сборки версий KDE, более новых, чем включены в релиз) или оконных менеджеров (таких, как репозиторий пакетов для Enlightenment DR17 – Slack64e14;

• наконец, личные репозитории энтузиастов – самым известными являются хранилища пакетов, собранных Эриком Хамелирсом (Eric Hameleers, также известный как Alien Bob и Alien Pastures) для применителей из СШАи иных стран.

Более подробно о неофициальных репозиториях Slackware можно прочитать Приложении.

Разумеется, все найденные репозитории Slackware не следует сразу же вписывать в /etc/slapt-get/slapt-getrc и немедленно выполнять тотальное обновление кеша, а затем и пакетов. Как раз наоборот, делать этого не следует: неофициальные репозитории развиваются сами по себе, часто содержат разные версии одного и того же пакета, да ещё и их зависимости могут быть несколько разными. Так что при таком огульном подключении вполне вероятны конфликты.

Так что лучше вписать неофициальные репозитории с необходимыми пакетами в альтернативный конфигурационный файл (например, /etc/slapt-get/slapt-get-ktownrc для использования новых версий KDE), и для обращения к его содержимому использовать slapt-get с опцией --config [имя файла].

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

В седьмой главе описывается Gslapt – графическая надстройка над утилитой slapt-get, рассказывается о её практическом применении и настройке. А также даётся общее заключение о целесообразности их параллельного применения, как взаимодополняющих инструментов для работы с пакетами.

Если утилиту slapt-get в какой то мере можно считать созданной по мотивам утилит семейства APT, то её графическая оболочка Gslapt – оригинальная разработка, созданная специально для Slackware. Однако как неотъемлемая часть системы она присутствует только в Salix (и Vector Linux).

В дистрибутиве Salix Gslapt устанавливается по умолчанию в обоих вариантах с графической средой. Он запускается из раздела Системаглавного меню через одноимённый пункт, предварительно запрашивая пароль пользователя. Что осуществляется через утилиту gksu – графическую надстройку над командами su и sudo (в данном случае, по понятным причинам, используется вторая).

Рисунок 7-1. Запрос пароля пользователя перед запуском Gslapt

Первое действие, требуемое после запускаGslapt – запрос на получение списка пакетов для подключённых репозиториев. Причём это необходимо в любом случае – даже если этот список уже был получен ранее консольной утилитой slapt-get (почему – будет сказано в разделе о настройке Gslapt).

После этого Gslapt выглядит примерно таким образом:

Рисунок7 -2. Gslapt: первый запуск