Для ответа на этот вопрос достаточно обратиться к каталогу /x86_64/slackware-14.1, родительскому по отношению к тому, что был приведён на рис. 2. И там обратить внимание на подкаталог dep.
Рисунок 6-4. Основные каталоги ветки Slackware
Зайдя в него, можно обнаружить множество файлов с маской *.dep – по суммарному количеству пакетов в ветке Slackware. В них-то и описаны зависимости для пакетов, заимствованных из прародительского репозитория, ни о каких зависимостях и не подозревающего. Например, в файле zsh.dep можно увидеть следующее:
gdbm,ncurses
Наличие подкаталога с файлами зависимостей – второе (наряду с составом пакетов) отличие ветки Slackware в репозитории Salix отличие последнего от официального репозитория «головного» дистрибутива.
Ну а вынесены эти файлы в отдельный подкаталог из соображений, можно сказать, этических: дабы сохранить структуру ветки, заимствованной из Slackware, в неприкосновенности. То есть подкаталог /x86_64/slackware-14.1/deps – своего рода мега-патч для репозитория, обеспечивающий контроль зависимостей в хранилище пакетов, изначально на это не рассчитанном.
Заодно можно ответить и на другой вопрос: почему slapt-get не получил широкого распространения в самой Slackware и, за некоторыми исключениями, в её клонах? Первая часть ответа очевидна: в официальном репозитории исходного дистрибутива никаких описаний зависимостей не содержится. И в этом случае slapt-get теряет большинство своих преимуществ – более эффективной системой управления пакетами оказывается slackpkg. Для разработчиков же любых клонов Slackware включить slapt-get в штатный комплект своего дистрибутива недостаточно: надо также создать репозиторий с поддержкой зависимостей, а главное – поддерживать его в актуальном состоянии. Что, понятно, является нелёгкой и не очень увлекательной работой, к которой мало кто из энтузиастов оказался готов. Насколько я знаю, единственный, кроме Salix, дистрибутив, где такая работа ведётся – это Vector Linux. Но он и создавался изначально как система, предназначенная, в том числе, и для коммерческого распространения.
Теперь, зная, как устроены репозитории Salix, можно вернуться к утилите slapt-get – точнее, к её настройке. Потому что большая часть последней – как раз и есть обеспечение доступа к репозиториям.
Все настройки slapt-get хранятся в файле /etc/slapt-get/slapt-getrc. Это простой текстовый файл, который можно условно разделить на три неравные секции.
Первая секция самая маленькая, и состоит из одной строки, определяющей каталог для локального кеша репозиториев и мета хранения устанавливаемых пакетов. По умолчанию это
WORKINGDIR=/var/slapt-get
И менять её без веских оснований не следует (я таких оснований не вижу). А вот посмотреть на её содержимое не вредно:
$ ls /var/slapt-getpackage_data patches/ salix/ slackware64/
Самое главное здесь – файл package_data: это «интегрированная» локальная копия файлов PACKAGES.TXT всех подключённых репозиториев, создаваемая командой
$ sudo slapt-get —update
Тот самый файл, без которой slapt-get отказывается выполнять какие-либо иные действия.
Назначение подкаталогов очевидно: в них хранятся скачанные при установке пакеты из соответствующих ветвей репозитория, с разбивкой на серии. О чём следует помнить, если возникнет необходимость переноса пакетов на машину, не имеющую подключения к сети.
Вторая секция также содержит единственную строку, хотя и несколько более длинную:
^rootuser-settings,^zzz-settings.*,-i?86-
Это – те самые исключения, то есть маски имён пакетов, не затрагиваемых обновлениями по команде
$ sudo slapt-get --upgrade
А также – автоматическими обновлениями, о которых будет говориться в части седьмой. Удалять из этой строки ничего не следует. При необходимости обновить, например, ядро системы это можно сделать, явным образом добавив опцию --ignore-excludes к команде установки пакета, например:
$ sudo slapt-get --install --ignore-excludes kernel-huge
А вот необходимость пополнить список исключений может возникнуть – например, пакетам, имеющимися в штатном репозитории, но собственноручно пересобранными с какими-либо специфическими опциями.
Наконец, третья секция – это список доступных репозиториев. По умолчанию он выглядит так (если при первичной установке не было выбрано другое зеркало):
# The Slackware repositories, including dependency informationSOURCE=http://salix.hostingxtreme.com/x86_64/slackware-14.1/:OFFICIAL SOURCE=http://salix.hostingxtreme.com/x86_64/slackware-14.1/extra/:OFFICIAL # The Salix repository SOURCE=http://salix.hostingxtreme.com/x86_64/14.1/:PREFERRED # Local repositories # SOURCE=file:///var/www/packages/:CUSTOM
И если, повторяю, при инсталляции не было выбрано зеркало, отличное от «умолчального», эту секцию править можно, а скорее всего, и нужно: сервер HoaringXtreme в наших условиях не поражает скоростью доступа к нему.
На странице Repository mirrors сайта проекта приведён список всех зеркал мастер-репозитория Salix. Для тех, что доступны по протоколу HTTP, я с помощью утилиты ping проверил время отклика – результаты сведены в таблице.
Таблица 6-1. Время отклика зеркал официального репозитория Salix
Зеркало Страна Время, мсек ftp.nluug.nl/os/Linux/distr/salix Нидерланды 60 ftp.belnet.be/salixos.org Бельгия 66 salix.enialis.net Франция 70 mirror.inode.at/data/salix Австрия 71 slackware.org.uk/salix Англия 77 ftp.heanet.ie/pub/salix Ирландия 84 mirrorservice.org/sites/download.salixos.org Англия 85 salix.mirror.garr.it/mirrors/salix Италия 85 mirrors.nix.org.ua/linux/salixos Украина 94 ftp.nux.ipb.pt/dists/salix Португалия 110 ftp.cc.uoc.gr/mirrors/linux/salix Греция 115 salix.hostingxtreme.com США, Огайо 161 mirror.its.dal.ca/salix Канада 167 mirrors.xmission.com/salix США, Юта 198 mirror.bjtu.edu.cn/salix Китай н./с. www.gtlib.gatech.edu/pub/salixos США, Джорджия н./с. download.salixos.org Франция н./с.
Примечание: сервера в таблице приведены в порядке возрастания времени отклика; н./с. – нет соединения.
Разумеется, данные в таблице приведены только для общей ориентировки – они зависят от многих факторов, и у читателя могут быть другими. Однако в целом можно констатировать, что для России все «заокеанские» сервера, включая и предлагаемый по умолчанию, – не лучший выбор. Я обычно выбираю Нидерландский или Бельгийский серверы – в условиях Москвы они хорошо показывают себя и для зеркал многих других дистрибутивов.
Дополнительные репозитории
Количество пакетов в репозитории Salix по определению ограниченно – разработчики этого дистрибутива принципиально не стремились объять необъятный мир свободного программного обеспечения. Поэтому вполне реальна ситуация, когда применитель не обнаружит жизненно важного или любимого пакета. И тут восполнить «недостачу» можно двумя способами.
Один из них – сборка недостающих пакетов из исходных текстов. Разумеется, не в «лобовом» варианте, с помощью трёх волшебных заклинаний./configure, make, make install: этот путь очень быстро приведёт к захламлению системы, и прибегать к нему следует в самом крайнем случае. Да в нём нет и необходимости: от Slackware дистрибутив Salix унаследовал механизм работы с так называемыми слакбилдами (Slackbuilds) – сценариями автоматизированной сборки пакетов. И, более того, укрепил и расширил их, в том числе с помощью графической оболочки к консольным средствам. Но этот путь будет рассмотрен в одной из ближайших частей.
Потому что есть путь другой, который представляется более простым. Как неоднократно подчёркивалось на протяжении всего цикла, Salix сохраняет полную бинарную совместимость со Slackware на уровне пакетов. Так что почему бы не попробовать поискать пакеты, отсутствующие в штатном репозитории дистрибутива, среди хранилищ пакетов, не имеющих официального статуса, то есть созданных и поддерживаемых энтузиастами для прародительской системы?
Неофициальные репозитории Slackware – это своего рода налоги PPA-репозиториев Ubuntu или «домашних» репозиториев openSUSE. Они не столь многочисленны, как последние (и, тем более, первые). Но имеют место быть, причём некоторые из них развиваются уже многие годы, возникнув задолго до создания PPA и OBS. Среди них можно видеть
• репозитории «братских» дистрибутивов, подобно Salix, сохраняющих полную совместимость со Slackware (например, репозиторий дистрибутива Slackel;
• репозитории для сборки специализированнх систем – примером может послужить Microlinux Enterprise Desktop (или просто MLED);
