Книга: Погружение в 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, которая будет предметом рассмотрения в седьмой главе.

Оглавление книги