архив
Zenwalk
Приобщение к Linux
2008-06-25
Глава 9. Zenwalk: репозитории, пакеты, методы установки
Введение
В главах 6 и 7 мы рассмотрели большую часть программ, предлагаемых нам дистрибутивом на штатном носителе, и убедились, что для начала работы их вполне достаточно. Но сколь бы много ни было программ в составе дистрибутива, обязательно найдётся хоть что-нибудь, чего данному конкретному пользователю не хватит. Тем более, что майнтайнеры Zenwalk'а принципиально не стремятся к всеохватности, помятуя мысль Козьмы Пруткова, что нельзя обнять необъятное.
Откуда брать дополнительный софт? Как всегда, в POSIX-мире на этот вопрос есть два ответа, Можно, следуя заветам Великого Патрика, собирать его самому из исходников. А можно — воспользоваться репозиториями Zenwalk'а, то есть хранилищами пакетов, собранных специально для этого дистрибутива. Собственно говоря, в данном случае есть и третий вариант ответа: воспользоваться репозиториями Slackware и её многочисленных клонов.
С первым путем всё понятно — он знаком каждому, кто когда-либо собирал пакеты руками. А кто этой дорогой еще не ходил — освоит её со временем, ничего сверхъестественно сложного там нет. И, вероятно, во второй части книги я еще вернусь к этой теме.
Третий путь вполне приемлем — все клоны Slackware более или менее сохраняют бинарную совместимость своих пакетов между собой и с родительской системой. Однако из-за возможных различий в файловой иерархии этот путь требует аккуратности и внимательности. Здесь мы о нём говорить не будем.
Так что ниже сконцентрируем свое внимание на изучении второго пути — использовании специальных репозиториев для Zemwalk'а. Собственно, он и рекомендуется разработчиками дистрибутива. На путь же третий и, тем более, первый следует ступать поначалу только тогда, когда позарез нужной программы в "родных пенатах" не обнаружится.
О репозиториях
Репозитории Zenwalk бывают официальные и неофициальные. Список первых перечислен в файле /etc/netpkg.conf — конфигурационном файле пакета netpkg, о котором скоро пойдет речь. Они содержат все пакеты, штатно поддерживаемые разработчиками дистрибутива (разумеется, и те, что имеются на установочном диске).
Неофициальные репозитории поддерживаются отдельными пользователями самостоятельно. Их можно поискать в каталогах типа people на серверах, содержащих официальные репозитории. Обычно там можно найти ограниченное число пакетов, не вошедших в официальные репозитории, но интересных для их майнтайнеров.
В отличие от большинства аналогичных проектов, в Zenwalk'е нет понятия "головного" репозитория, зеркалируемого всеми остальными. Насколько я понял, все официальные зеркала являются вполне равноправными.
Официальные репозитории разделяются на группы current и snapshot. Первая — аналог того, что в большинстве иных дистрибутивов называется stable, то есть текущая стабильная ветка, в которой в промежутках между релизами смена версий пакетов не происходит (за редким исключением — пример см. ниже), в них вносятся лишь незначительные коррективы, касающиеся безопасности и оперативного исправления ошибок.
Всем памятна история с очередной сменой протоколов ICQ, после которой многие ICQ-клиенты для "альтернативных" операционок отказались работать. Так вот, обновленный пакет (тот самый редкий случай смены версии внутри ветки current) для штатного Zenwalk'овского ICQ-клиента, pidgin'а, разрешающий эту проблему, появился через считанные часы после её выявления.
Группа snapshot — это более или менее регулярный слепок разрабатываемой версии, которой рано или поздно предстоит стать релизом. Поскольку релиз-цикл у Zenwalk очень короткий, обновления, хотя и появляются очень быстро, в количественном отношении обычно не столь уж значительны (за исключением ключевых компонентов дистрибутива, изменения которых, собственно, и диктуют выпуск нового релиза).
Поэтому причине снапшоты обычно вполне стабильны, и есть резон использовать именно их. Это обеспечивает как более современные версии пакетов, так и некоторые дополнительные возможности. Так, например, в настоящее время пакет OpenOffice.org в ветке current представлен версией 2.4.0, и, к тому же, без дополнительного пакета русской локализации. В snapshot'е же мы видим версию 2.4.1, и плюс к ней русифицирующий пакет.
Далее, в обеих группах можно выделить официальную часть (она никак не именуется, содержащие её каталоги называются просто current/ и snapshot/) и, так сказать, полуофициальную — restricted/current/ и restricted/snapshot/). Хотя обе они официально поддерживаются разработчиками дистрибутива, в основной группе (аналог группы Main в репозиториях Dibian-клана) содержатся только соверщенно свободные (в понимании FSF) программы, а в репозитории restricted/ (соответствуют одноименной группе в Debian'овских репозиториях) выделены программы, распространение которых может ограничиваться законами некоторых слабо развитых в правовом отношении государств. И мы знаем каких — тех самых, которые признают патенты на алгоритмы и программы... То есть это не какой-то Linux'овый warez, и гражданам России и большинства прочих стран волноваться на этот предмет нечего.
Внутреннее устройство репозиториев можно рассмотреть на примере любой строки из соответствующей секции файла /etc/netpkg.conf. Для определенности возьмём секцию
# Current repository (the most stable, with only security and bug fixes)
и в ней строку
Internet_mirror = http://zen-repo.meticul.eu/i486/current
Если открыть приведенный URL в браузере, то мы увидим примерно следующую картину (рис. 9.01):
Рис. 9.01. Внутреннее устройство репозитория
Файлы PACKAGES.TXT и CHECKSUMS.md5 — это полное описание пакетов репозитория и список контрольных сумм каждого пакета соответственно, а PACKAGES.TXT.gz и CHECKSUMS.md5.gz — их компрессированные аналоги.
Подкаталоги же — это т.н. категории, унаследованные от Slackware. Значение обозначающих их литер таково:
- a/ — приложения базовой системы;
- ap/ — дополнительные, преимущественно пользовательские, приложения текстового режима;
- d/ — средства разработки и всё, что с ними связано;
- l/ — основные системные библиотеки;
- n/ — сетевые средства;
- x/ — пакеты, составляющие оконную систему X (точнее, Xorg);
- xap/ — приложения графического режима, включая менеджеры окон и рабочую среду Xfce.
В этих подкаталогах при внимательном рассмотрении можно обнаружить все пакеты с дистрибутивного диска — и только их. Так откуда же берутся пакеты дополнительные? Ответить нетрудно — все они собраны в подкаталоге extra/. Он также разбит на вложенные подкаталоги, соответствующие категориям, только тут их гораздо больше (рис. 9.02).
Рис. 9.02. Внутреннее устройство репозитория
Кроме основных категорий системы, именованных теми же литерами и имеющих то же содержание (разумеется, по назначению, не буквально), здесь можно видеть такие подкаталоги как:
- e/ — все имеющее отношение к Enlightenment, бывшему оконному менеджеру, который, начиная с разрабатываемой версии 0.17 (а именно она здесь и представлена) претендует на звание интегрированной среды;
- f/ — подборки разнообразных FAQ и How-to, а также man-страниц для дополнительных пакетов (на французском языке);
- g/ — интегрированная среда GNOME и её приложения;
- games/ — понятно без комментариев;
- kde/ — интегрированная среда KDE с её многочисленными приложениями, как штатными, так и дополнительными, вроде amarok или kaffeine; в настоящее время KDE представлена в версии 3.5.9, но обещано, что 4-я ветка появится в репозиториях сразу по выходе версии 4.1;
- locale/ — пакеты локализации для самых различных программ, включая KDE, KOffice и OpenOffice;
- s/ — "серверные" пакеты, такие как Apache, MySQL, PHP, Samba и так далее;
- t/ — Tetex;
- tcl/ — одноименный язык программирования.
Структура каталогов в репозиториях snapshot/ идентична описанной. А репозитории restricted/ и restricted/snapshot/ не имеют деления на категории. Что же касается репозиториев неофициальных, которые в изобилии представлены, например, на сервере Ibiblio.org, то они могут как разделяться на категории (список которых по понятным причинам урезан по сравнению с основными репозиториями), так и содержать просто отдельные файлы.
С некоторых пор основным хранилищем неофициальных, поддерживаемых сообществом, пакетов стал ZUR (Zenwalk User Repository). В его устройстве есть некторая специфика, которая определяет и специфику его использования. Так, наряду со стандартными катгориями типа a, ap и так далее, в том же ранге выделяются категории extra-a, extra-ap и еше многие дополнительные (рис. 9.02-1).
Рис. 9.02-1. Структура категорий ZUR
Назначение, устройство и методы использования ZUR описаны в документе ZUR FAQ (русский перевод). К сказанному там добавлю только, что большинство пакетов ZUR представляют собой тестовые версии, и потому этот репозиторий не предназначен для автоматической установки и обновления пакетов через netpkg. Скорее его компоненты должны устанавливаться в старых добрых традициях Slackware через installpkg, с тщательным отслеживанием зависимостей.
Возвращаемся к основным репозиториям. Собственно пакеты находятся внутри категорий каталогов current/ или current/extra. Это файлы вида *.tgz, формат которых целиком унаследован от Slackware — то есть это "чистые" тарбаллы (tar-архивы, сжатые утилитой gzip), содержащие, кроме откомпилированных бинарников, только пре-инсталляционный и пост-инсталляционный сценарии. То есть — без всякой метаинформации о зависимостях.
Однако ранее вскользь уже говорилось (и подробно будет говориться далее), что одной из отличительных черт дистрибутива Zenwalk является именно развитая система управления пакетами, успешно "разруливающая" те самые зависимости, о разрешении которых пользователь Slakware должен заботиться сам. Так откуда же пакетный менеджер netpkg берет информацию о них?
Чтобы ответить на этот вопрос, обратимся еще раз к содержимому какой-либо категории (пусть для определенности это будет extra/ap). И мы увидим, что каждому пакету соответствуют аж четыре файла. Если взять для примера тот же joe, то это будут:
- joe-3.5-i486-1.dep
- joe-3.5-i486-1.meta
- joe-3.5-i486-1.tgz
- joe-3.5-i486-1.txt
О joe-3.5-i486-1.tgz мы уже говорили, это сам бинарный пакет, внутри которого можно видеть исполняемый бинарник, конфигурационные файлы, файлы man-страниц и так далее.
Файл joe-3.5-i486-1.dep — это как раз и есть перечень зависимостей, выглядящий для joe так:
coreutils,ncurses
Файл joe-3.5-i486-1.txt — краткое описание пакета и указание на его авторство:
joe: joe (Joe text editor) joe: joe: Joseph H. Allen's easy to use text editor, similar to WordStar[tm]. joe: ... joe:
Ну, а файл joe-3.5-i486-1.meta — своего рода "результирующая" метаинформация о пакете:
PACKAGE NAME: joe-3.5-i486-1.tgz PACKAGE LOCATION: ./extra/ap PACKAGE SIZE (compressed): 338 K PACKAGE SIZE (uncompressed): 1010 K PACKAGE REQUIRED: coreutils,ncurses PACKAGE CONFLICTS: PACKAGE SUGGESTS: PACKAGE DESCRIPTION: joe: joe (Joe text editor) joe: joe: Joseph H. Allen's easy to use text editor, similar to WordStar[tm]. joe: ... joe:
Здесь PACKAGE NAME — полное имя пакета, образованное из его basename (joe), номера версии (3.5), целевой архитектуры (i486) и номера сборки (1) для конкретной версии дистрибутива (в следующем релизе нумерация начнется сначала).
Остальные строки, думаю, понятны без комментариев, за исключением разве что PACKAGE SUGGESTS — это те самые пресловутые "мягкие" (или необязательные) зависимости. В данном примере они отсутствуют — то есть майнтайнер пакета не счёл нужным их описывать.
Именно из совокупности содержимого файлов *.meta для каждого пакета и слагается суммарный файл PACKAGES.TXT. Который в итоге и является источником метаинформации для менеджера пакетов.
Однако прежде чем переходить к системе управления пакетами Zenwalk, рассмотрим, какими средствами он располагает для обращения с пакетами единичными.