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

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

Серии пакетов Slackware: вместо введения

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

Во всех развитых системах пакетного менеджмента существует понятие так называемых метапакетов (metapackages), хотя они носят разные имена, Во FreeBSD, из которой и пошло это понятие, они называются метапакетами и метапортами, в дистрибутивах, использующих формат пакетов deb – задачами (tasks), в openSUSE – шаблонами (patterns), в Fedora – группами (groups). Однако суть остаётся одна и та же. Метапакет – это список тем или иным образом связанных пакетов, которые могут быть установлены, обновлены и, в некоторых случаях, удалены одной командой.

В Slackware и её клонах (в том числе и в Salix) аналогом метапакетов являются серии или наборы пакетов (series или sets). Классический список таких серий, сформированный в незапамятные времена зарождения прародительской системы, включает следующие компоненты:

• a – минимальный набор пакетов для функционирования системы в консольном режиме;

• ap – консольные приложения и утилиты, выходящие за пределы необходимого минимума;

• d – инструментарий для разработки и сборки программ;

• e – GNU Emacs и всё, что имеет к нему отношение;

• f – различная общесистемная документация, включая FAQ и HOWTO;

• k – исходные тексты ядра Linux;

• kde – пакеты, в сумме образующие одноименную интегрированную среду и необходимые для её работы библиотеки;

• kdei – пакеты интернационализации для среды KDE и её приложений;

• l — библиотеки общего назначения, от общесистемной glibc до Qt и Gtk;

• n – программы для работы с сетью;

• t – TeX и всё, что с ним связано;

• tcl – интерпретатор языка TCL и связанный с ним инструментарий;

• x — оконная система X, то есть Xorg, включая X-сервер, драйверы устройств ввода-вывода и видеоподсистемы и так далее;

• xap – приложения графического режима, не входящие в базовую систему Xorg, включая оконные менеджеры;

• xfce – одноимённый интегрированный десктоп и его штатные приложения;

• y – древние консольные игры, идущие ещё из BSD-систем.

В Salix'е действенны все наборы материнской системы, однако есть и некоторые собственные:

• games – игры, заменяющие доисторический набор f (которого здесь нет);

• gnome – приложения для одноимённой среды, несколько лет назад исключённой из официального репозитория самой Slackware;

• locale – пакеты локализации для LibreOffice, Firefox и Thunderbird;

• lxde – рабочая среда LXDE и её штатные приложения;

• mate – современный клон GNOME 2.

Любая из серий пакетов может быть установлена одной командой – для этого в slapt-get предусмотрена специальная цель:

$ sudo slapt-get --install-set [имя серии]

Принцип комплектования серий пакетов в Slackware несколько иной, нежели, скажем, задач в Ubuntu: подобно шаблонам в openSUSE, это скорее тематические группы, нежели целевые наборы типа ubuntu-desktop. И, помимо «канонических» серий Slackware, таких, как a, ap и так далее, собственные наборы пакетов могут создаваться достаточно произвольно: для этого достаточно поместить соответствующие пакеты в один каталог, который дополняется так называемым файлом тегов (tagfile), содержащим их перечень. Однако slapt-get оперирует не сериями пакетов, а их репозиториями, к рассмотрению которых мы наконец и переходим.

Репозитории Salix

Применение к репозиториям Salix множественного числа несколько условно. В сущности, здесь мы имеем дело с единым хранилищем пакетов (и его официальными зеркалами), а не такими сложно структурированными конструкциями, как официальные и полуофициальные (semi-official) репозитории openSUSE или репозитории main, universe, restricted и multiverse в Ubuntu, не говоря уже о её бесчисленных PPA-репозиториях. Впрочем, нечто вроде аналога последних (или «домашних» репозиториев openSUSE) в Slackware и в Salix тоже имеется, но об этом речь пойдёт главе 8.

А пока рассмотреть устройство репозитория Salix проще всего на конкретном примере – например, мастер-сервера проекта. Здесь можно видеть сборки пакетов для каждой из поддерживаемых архитектур – x86 (именуемой i486) иx 86_64. Есть ещё и сборка для процессоров ARM, но это вещь специфическая, и я о ней говорить не буду. Далее речь пойдёт о линии x86_64, как более актуальной.

Внутри каждой «архитектурной линии» обособляются две ветви – репозитории собственно Salix и репозитории Slackware, каждая с разделением на версии (от первой, 13.0 до текущей, 14.1 – впредь будет подразумеваться последняя).

Рисунок 6-1. Корневой каталог репозитория для 64-разрядной архитектуры

Поскольку разработчики Salix, как они сами подчеркивают в упоминавшемся в первой главе интервью, развитие базовой системы передоверили «головной организации», основная часть пакетов дистрибутива хранится в каталоге /salix/x86_64/slackware-14.1/ – его одноимённом подкаталоге slackware64 и extra. Он же представляет собой почти точное зеркало соответствующих ветвей официального сервера родительского дистрибутива – за двумя важными исключениями.

Первое – «сдублированы» не все пакеты Slackware, а только те, которые задействуются в дистрибутиве Salix. О втором же исключении я скажу чуть позже.

В основной части «головной» ветки репозитория, то есть в каталоге /x86_64/slackware-14.1/slackware64, можно видеть те самые серии пакетов, о которых говорилось в предыдущем разделе, а также несколько служебных файлов:

CHECKSUMS.md5 CHECKSUMS.md5.asc FILE_LIST MANIFEST.bz2 PACKAGES.TXT

Рисунок 6-2. Ветка репозитория Salix, заимствованная из прародительского дистрибутива

Важнейшим из них является файл PACKAGES.TXT, содержащий перечень всех пакетов с характеристикой каждого – той самой, которое выводит команда slapt-get при указании цели show и имени пакета. Например, для пакета zsh она выглядит так:

PACKAGE NAME: zsh-5.0.2-x86_64-1.txz PACKAGE LOCATION: ./slackware64/ap PACKAGE SIZE (compressed): 2428 K PACKAGE SIZE (uncompressed): 9340 K PACKAGE REQUIRED: gdbm,ncurses PACKAGE CONFLICTS: PACKAGE SUGGESTS: PACKAGE DESCRIPTION: zsh: zsh (the Z shell) zsh: zsh: Zsh is a UNIX command interpreter (shell) which of the standard shells zsh: most resembles the Korn shell (ksh), although it is not completely zsh: compatible. It includes enhancements of many types, notably in the zsh: command-line editor, options for customizing its behavior, filename zsh: globbing, features to make C-shell (csh) users feel more at home and zsh: extra features drawn from tcsh (another 'custom' shell). Zsh waszsh: written by Paul Falstad. zsh:

Остальные файлы каталога, а их может быть больше, чем приведено на скришноте, также важны. Так, файл, CHECKSUMS.md5 содержит контрольные суммы файлов, подтверждающие их «неизменность», файл GPG-KEY, расположенный в родительском каталоге, включает ключи, удостоверяющие их «подлинность», и так далее. Однако именно наличие файла PACKAGES.TXT волшебным образом превращает обычный каталог с файлами пакетов на локальном диске или удалённом сервере в их репозиторий.

Переходим глубже, в подкаталог одной из серий – и там видим уже собственно файлы пакетов и по два файла со служебной информацией. Например, для того же пакета zsh (в серии ap) они таковы:

• zsh-5.0.2-x86_64-1.txz – архив с бинарным исполняемым файлов, документацией и прочими компонентами пакета;

• zsh-5.0.2-x86_64-1.txt – краткое описание пакета;

• zsh-5.0.2-x86_64-1.txz.asc – контрольная сумма для проверки целостности архива.

Всё – больше никакой информации в репозитории Slackware вроде бы не содержится. В том числе – и никакой информации о зависимостях пакетов.

Теперь обратимся к дистрибутив-специфичной ветке репозитория Salix, то есть к каталогу /x86_64/14.1. Он содержит пакеты, либо отсутствующие в официальном репозитории Slackware (например, slapt-get, описанный в пятой части цикла, его графическую оболочкуGslapt, о которой речь пойдёт в части седьмой, и некоторые другие), либо пакеты, которые разработчики дистрибутива по тем или иным причинам сочли необходимым собрать по своему (например, mozille-firefox). Здесь мы видим те же служебные файлы PACKAGES.TXT с «аннотированным» списком пакетов, GPG-KEY с колючами, ChangeLog.txt с описанием обновлений репозитория, и другие.

Рисунок 6-3. Дистрибутив-специфическая ветка репозитория Salix

Отправившись «глубже», в подкаталог salix, можно обнаружить серии пакетов, в том числе и специфические для дистрибутива, например, серию mate, а в ней – отдельные пакеты. Но здесь на каждый индивидуальный пакет приходится уже пять файлов. Например, для пакета caja (файловый менеджер – форк Nautilus из GNOME2) это будут:

caja-extensions-1.8.0-x86_64-1gv.dep caja-extensions-1.8.0-x86_64-1gv.md5 caja-extensions-1.8.0-x86_64-1gv.meta caja-extensions-1.8.0-x86_64-1gv.txt caja-extensions-1.8.0-x86_64-1gv.tx

Содержимое трёх из них (*.txz, *.txt и *.md5) мы уже знаем, а что же такое файлы *.dep и *.meta? Узнать это легко, если их просмотреть. Первый – это описание тех самых пресловутых зависимостей для пакета:

atk,bzip2,cairo,cxxlibs|gcc-g++,dconf...

А файл *.meta – результирующая метаинформация:

PACKAGE NAME: caja-extensions-1.8.0-x86_64-1gv.txzPACKAGE LOCATION: ./salix/mate PACKAGE SIZE (compressed): 78 K PACKAGE SIZE (uncompressed): 312 K PACKAGE REQUIRED: atk,bzip2,cairo,cxxlibs|gcc-g++,dconf,expat,fontconfig,freetype,gcc,gdk-pixbuf2,glib2,gtk+2,harfbuzz,icu4c,libX11,libXau,libXcomposite,

libXcursor,libXdamage,libXdmcp,libXext,libXfixes,libXi,libXinerama,libXrandr,libXrender,libXxf86vm,libdrm,libffi,libpng,libxcb,mate-desktop,mate-file-manager,mesa,pango,pixman,startup-notification,udev,xcb-util,zlib PACKAGE CONFLICTS: PACKAGE SUGGESTS: ...

Можно видеть, что она включает в себя не только «жёсткие» зависимости (PACKAGE REQUIRED), но может описывать и зависимости опциональные («мягкие» – PACKAGE SUGGESTS), а также конфликтующие пакеты, если те и другие имеются (в примере их нет). Именно благодаря этой метаинформации slapt-get может не только отслеживать зависимости пакетов при их установке, но и разрешать их автоматически.

И тут читатель вправе задать вопрос: если «специфическая» часть репозитория охватывает меньшинство пакетов Salix, а большинство их берётся с зеркала репозитория Slackware, то как зависимости контролируются для них? Ведь там в сериях пакетов мы не видели и намёка на описания зависимостей.

Для ответа на этот вопрос достаточно обратиться к каталогу /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. Но он и создавался изначально как система, предназначенная, в том числе, и для коммерческого распространения.

Настройка slapt-get

Теперь, зная, как устроены репозитории 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

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

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

Дополнительные репозитории

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