• 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 множественного числа несколько условно. В сущности, здесь мы имеем дело с единым хранилищем пакетов (и его официальными зеркалами), а не такими сложно структурированными конструкциями, как официальные и полуофициальные (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, то как зависимости контролируются для них? Ведь там в сериях пакетов мы не видели и намёка на описания зависимостей.
