архив
Zenwalk
Приобщение к Linux
2008-06-25
Средства установки пакетов
Для манипулирования единичными пакетами в Zemwalk имеется комплекс утилит, унаследованных от Slackware: installpkg, explodepkg, upgradepkg, removepkg, makepkg.
Назначение их более или менее понятно из названий. Так, installpkg — это средство для установки единичного пакета. Оно требует в качестве аргумента имени файла устанавливаемого пакета (в полной форме, включая номер версии, сборки, архитектуру и суффикс) и пути к нему. После запуска такой командной директивы (разумеется, команда должны выполняться от лица администратора) выводится описание пакета, сообщение о запуске инсталляционного скрипта, и возвращается приглашение командной строки (рис. 9.03).
Рис. 9.03. Установка пакета с помощью installpkg
Это означает, что пакет был благополучно установлен, и сведения о нем занесены в базу данных установленных пакетов, каковая имеет место быть в каталоге /var/log/packages/, куда попадают данные о всех пакетах, установленных штатным образом — с дистрибутивного носителя при первичной установке системы, с помощью средств установки или пакетного менеджера.
Сведения об установленных пакетах содержатся в одноименных им файлах вида pkg_name-version-architecture-revision. Это простые текстовые файлы, содержащие, во-первых, описание пакета, а во-вторых (и это самое главное), список всех его компонентов с указанием полных путей, отсчитываемых от корневого каталога, примерно в таком виде :
usr/ usr/bin/ usr/bin/a2ps ... usr/doc/ usr/doc/a2ps-4.13b/ usr/doc/a2ps-4.13b/ABOUT-NLS ... usr/include/ usr/include/liba2ps.h usr/info/ usr/info/a2ps.info-2.gz ... usr/lib/ usr/lib/liba2ps.a usr/lib/liba2ps.la usr/man/ usr/man/man1/ usr/man/man1/epsffit.1.gz ... usr/share/ usr/share/a2ps/ usr/share/a2ps/README
и так далее. Обращаем внимание, что в этом списке содержатся файлы только самого авторского пакета, тогда как в его архиве имелись и установочные скрипты (атрибут только пакетов Slackware). Скрипты эти при установке попадают в самостоятельный каталог — /var/log/scripts. Вся эта информация будет затребована при удалении пакета, если в этом возникнет необходимость.
Возвращаясь к installpkg, заметим, что с его помощью пакет будет установлен (то есть распакован и включён в файловую иерархию) в любом случае. Другой вопрос, будет ли он работать. Приведенный на рис. 9.03 пример с текстовым редактором jed имеет благоприятный исход: в зависимостях этого пакета значатся gpm и slang, которые ранее в системе были установлены, и потому jed заработает без проблем.
Если же мы попытаемся тем же образом установить пакет, зависящий от каких-либо отсутствующих библиотек, то никаких сообщений об ошибках не последует, и, более того, исполняемый файл пакета обнаружится на месте (например, в /usr/bin). Однако запустить его не удастся: уж тут-то последует сообщение об ошибках, связанных с отстутствием таких-то и таких-то библиотечных файлов. Заметьте, файлов — а не библиотечных пакетов, эти файлы содержащих. Так что вычислить зависимости по таким сообщениям окажется задачей, не вполне тривиальной.
Тем не менее, для установки единичных пакетов с простыми (или хорошо известными) зависимостями использование installpkg — самый прямой путь. Однако не советую ступать на него при установке, скажем, KDE — развлечение вам будет гарантировано надолго.
Утилита explodepkg имеет своей целью просто распаковку пакета в текущий каталог. Аргументом её также служит имя пакета в полной форме и путь к нему. При использовании этой утилиты следует помнить, что она полагает текущий каталог корневым в системе и, соответственно, помещает извлекаемые компоненты пакета в подкаталоги типа usr/bin, /usr/share и так далее. То есть запуская explodepkg из домашнего каталога, мы получим в нём много хлама.
Собственно, назначение утилиты explodepkg чисто образовательное — с её помощью можно изучить состав пакета и его структуру. Это особенно важно, если устанавливать в Zenwalk'е пакеты, собранные для Slackware или иных её клонов: из-за временами возникающих различий в файловой иерархии между дистрибутивами Slackware-based (например, использовании или неиспользовании каталога /opt) компоненты пакета могут оказаться не совсем там, где это ожидалось.
Утилита upgradepkg, как следует из её названия, выполняет обновление ранее установленного пакета до новой версии. Эта процедура заключается просто-напросто в удалении файлов старой версии и помещении на их место соответствующих новых комопнентов, хотя тут возможны ньюансы, с которыми можно ознакомиться на man-странице утилиты. Теоретически при этом конфигурационные файлы старой версии сохраняются, однако одноименная man-страница рекомендует сохранить их во избежание неприятностей.
Утилита removepkg, как нетрудно догадаться, отвечает за удаление ранее установленных программ. В качестве аргумента она требует только краткого имени (basename) удаляемого пакета, например:
$ removepkg jed
Команда такого вида отыщет в каталоге /var/log/packages/ файл, соответствующий пакету jed, определит из него пофайловый состав пакета и удалит все компоненты из соответствующих подкаталогов. При этом настроечные файлы пользователя, хранящиеся в его домашнем каталоге (файлы вида ~/.pkg_namerc и подобные, именуемые также dot-файлами), сохранятся. Избавиться от них (если это нужно) можно будет только вручную.
Сведения об удаленных пакетах заносятся в собственную базу данных — /var/log/removed-packages/, а о соответствующих им скриптах — в каталог /var/log/removed-scripts, которые устроены точно также, как и базы для установленных пакетов. В базе удаленных пакетов фиксируются и сведения о пакетах, подвернувшихся апгрейду (в результате использования утилиты upgradepkg или посредством системы пакетного менеджмента).
При удалении пакетов с помощью removepkg никакой контроль зависимостей, как и следует ожидать, не производится. То есть удалять пакеты, установленные только как зависимости данного и нигде более не используемые, придется вручную. Но это еще полбеды: с помощью removepkg можно спокойно удалить библиотечный пакет, от которого зависят другие пакеты, приведя, тем самым, последние в неработоспособное состояние. Иными словами, посредством removepkg можно добиться ничуть не менее превосходного результата по выведению системы из строя, чем знаменитой командой
# rm -Rf /
выданной от имени root'а (излишне напоминать, что для удаления пакета, как и для его установки, требуются привилегии администратора).
Наконец, утилита makepkg предназначена для создания собственных пакетов в формате Slackware (но без дополнительных файлов Zenwalk'а, содержащих метаинформацию). Однако о ней здесь речи не будет — тема создания пакетов будет предметом ближайшей интермедии.
Кроме единичных утилит манипулирования пакетами, в Zemwalk'е имеется также "синтетическое" средство того же назначения — pkgtool, также унаследованное от Slakware. Это — фронт-энд, обеспечивающий интерфейс для утилит установки и удаления программ (рис. 9.04)
Рис. 9.04. pkgtool — интерфейс к утилитам установки пакетов
Считается, что интерфейс этот более дружествен к пользователю, нежели интерфейсы отдельных утилит, составляющих бэк-энд pkgtool, однако это вопрос спорный. По моему скромному мнению, pkgtool удобен только для одной операции — установке одного или нескольких пакетов, файлы которых находящятся в текущем каталоге. Если устанавливаемый пакет лежит за пределами оного — потребуется указание не только полного пути к нему, но и полного имени соответствующего файла, причём на память, никакое автодополнение тут на помощь не придет.
Таким образом, все исконно Slackware'вские средства манипулирования пакетами, хорошо (с оговоркой на счет pkgtool) справляясь со своей целевой задачей, не обеспечивают разрешения зависимостей ни под каким соусом. С одной стороны, это хорошо: опытный пользователь может скомпоновать систему целиком по своему вкусу, без единого лишнего компонента.
С другой же стороны, поскольку совершенства в мире нет и не предвидится, это споособно доставить немало сложностей не только совсем уж начинающему пользователю, но и просто пользователю, недостаточно знакомому со спецификой Slackware и привычному к развитым системам пакетного менеджмента, каковые ко всем прочим дистрибутивам не прикрутил еще только суперленивый майнтайнер.
Поскольку майнтайнеров Zenwalk'а в лени упрекнуть трудно, то и их дистрибутив имеет систему управления пакетами, причем не заимствованную или адаптированную, а свою собственную. Она называется netpkg и существует в двух ипостасях — текстовой, запускаемой из командной строки, и графической, работающей в Иксах, причем функционально они не вполне идентичны. К рассмотрению их мы и переходим.
Система управления пакетами netpkg: консольная ипостась
Рассмотрение начнем, как обычно, с консольной ипостаси — утилиты netpkg. По своей идее она сходна с механизмом apt-get семейства Debian и особенно с утилитой pacman из Archlinux. В отличие от последней, netpkg не является производной от какой-либо системы построения пакетов типа портов. А по сравнению с apt-get она существенно проще в изучении и обращении. Правда, и возможности, предоставляемые ею, существенно меньше. Хотя в большинстве случаев их вполне достаточно.
При первом запуске netpkg выводится список доступных репозиториев — тех самых, которые перечислены в файле /etc/netpkg.conf, и устройство которых мы рассмотрели ранее. Из этого списка надлежит выбрать один репозиторий, который и будет служить главным источником пакетов в будущем. Правда, текущий репозиторий в дальнейшем можно и поменять — хотя процедура эта не самая удобная.
К слову сказать, список репозиториев в Zemwalk'е задаётся при инсталляции статически, из дистрибутива, а не генерируется в онлайне, как в Debian'е или Ubuntu. Что позволяет, в частности, провести установку Zemwalk'а без единого обращения к сети.
Возникает вопрос, какой же тип репозиториев выбрать: для главного источника пакета существует возможность выбора из current и snapshot. Поскольку restricted-репозитории, как и хранилища, поддерживаемые пользователями в индивидуальном порядке, содержат ограниченное число пакетов, и к тем и другим приходится обращаться лишь время от времени.
Как уже говорилось, пакеты из ветки snapshot мало уступают в стабильности таковым из ветки текущей — собственно говоря, я с примерами нестабильности просто не сталкивался, хотя и допускаю её вероятность. И потому я использую именно их с тех пор, как разобрался в устройстве репозиториев Zemwalk, благодаря чему всегда имею в своем распоряжении свежие версии ядра, видео-драйверов для X-сервера и тому подобных пакетов, важных для конечного пользователя.
С другой стороны, на серверах, где надежность важнее модерна, имеет смысл использовать один из репозиториев current/ — обновления безопасности и пакеты с "замеченными опечатками" с них будут получены, а новые возможности, предоставляемые свежими версиями ядра или X-сервера, здесь, как правило, не нужны.
Ну, а конкретное зеркало выбранного репозитория можно определить только методом ползучего эмпиризма. Я последнее время использую сервер Ibiblio.org для получения пакетов из ветки snapshot и неофициальных репозиториев, и сервер Meticul для обращения к группе restricted. Последнее, впрочем, я делаю исключительно для проверки — необходимости ни в одном пакете из этого репозитория до сих пор не возникло.
Оба выбранных мной сервера демонстрируют (в моих условиях) скорость отдачи вполне приличную, хотя и не рекордную. Впрочем, рекордов мне не удалось достигнуть ни на одном из зеркал репозиториев Zenwalk'а. Возможно, вам повезет больше.
Как уже говорилось, Zemwalk сохраняет (пока?) бинарную совместимость как с родительской Slackware, так и с большинством остальных её потомков. Так что напрашивается мысль о внесении в /etc/netpkg.conf соответствующих репозиториев на предмет доступа к недостающим у нас пакетам. Это, конечно, не возбраняется, но, по моему мнению, такие "двоюродные" пакеты при необходимости лучше устанавливать в ручном режиме с помощью описанных выше утилит, и только после проверки на совпадение целевых каталогов и версий пакетов-зависимостей.
Теперь пора переходить собственно к использованию netpkg. Оно начинается с того, что (при запуске этой команды в любой форме из описанных далее) происходит перечитывание (и, при необходимости, обновление) содержимого текущего репозитория. Что, с одной стороны, всегда поддерживает его в актуальном состоянии, с другой — затрудняет использование netpkg в условиях отсутствия подключения к Сети.
Собственно, способа использовать netpkg без подключения к Интернету я не знаю. Фокус с помещением заранее скачанных пакетов в локальный кэш (/var/packages), аналоги которого успешно применяются в дистрибутивах типа Gentoo, Archlinux, CRUX, в Zemwalk не проходит — как уже было сказано, первое, что делает netpkg при запуске, это лезет в Сеть на предмет синхронизации с текущим репозиторием.
Рассуждая теоретически, можно попытаться обмануть netpkg, сконфигурировав локальный кэш, как сетевое хранилище через loopback-соединение, но практически я этого не делал за ненадобностью (для меня). Может быть, кто-нибудь из читателей, для кого этот вопрос актуален, попробует и не поленится сообщить о результатах?
Вообще-то говоря, переключение репозиториев в консольном варианте netpkg не очень удобно. В качестве текущего лучше всего держать, как уже говорилось, одно из зеркал с веткой snapshot/ или current/, по потребностям. Если же нужно поискать иди установить какой-либо пакет среди restricted-хранилищ или неофициальных репозиториев, то придется сначала запустить команду
$ netkpg mirror
выбрать из списка подходящий пукнт, выполнить требуемые действия, а потом не забыть сделать прежний репозиторий текущим.
При установке единичного пакета или произвольного их количества использование netpkg настолько просто, что проще не придумаешь. Для этого достаточно набрать в командной строке
$ netpkg имя_пакета_1 [и_так_далее]
без указания пути, версии, суффикса и тому подобной атрибутики. После нажатия на Enter последует сообщение о том, что для удовлетворения зависимостей данного пакета требуется то-то и то-то. Если с этим согласиться, то необходимые для разрешения зависимостей пакеты будут установлены автоматически. Если отказаться — установка прервется. Оно и неудивительно — ведь все предлагаемые к установке зависимости являются "жёсткими", и без них пакет всё равно будет не работоспособным.
Дальше дело обстоит ничуть не сложнее. Утилита netpkg нашего дистрибутива имеет всего шесть опций:
- install — установка одного или нескольких пакетов, перечисленных в качестве аргументов опции; действует аналогично netpkg package_name без указания опций;
- upgrade — тотальное обновление системы, действует аналогично apt-get dist-upgrade в Debian'е и его клонах или pacman -Syu в Archlinux; можно запретить автоматическое обновление некоторых пакетов путем занесения их в "черный список конфигурационного файла (о чем будет сказано позднее); по умолчанию это часто делается для ядра;
- download — скачивание файлов из репозитория и помещение их в локальный кэш, расположенный в каталоге /var/packages/, с сортировкой по категориям, принятым в Zenwalk;
- list — вывод полного списка пакетов, имеющихся в репозитории, с указанием их категории (a/, extra/a/ и так далее) и статуса: I — установленный, U — подлежащий обновлению, D — «откатываемый» на более старую версию, N — не установленный (то есть новый); статус I и N также расшифровывается словами (installed и not installed, соответственно), кроме того, при соответствующих настройках шелла не исталлированные пакеты маркируются цветом;
- dotnew — поиск всех конфигурационных файлов в каталоге /etc/, помеченных как новые (*.new) и замена ими оригинальных версий;
- mirror — выбор одного из доступных репозиториев в качестве текущего.
Рис. 9.05. Вывод команды netpkg list
Сразу следует оговориться, что запуск netpkg с любой из опций по умолчанию требует привилегий root'а вне зависимости от того, приводит ли это к модификации корневной файловой системы (при установке пакетов, например) или нет (при выводе списка пакетов). Дело тут в том, что netpkg находится в каталоге /usr/sbin, по умолчаниям Zenwalk'а отсутствующем в списке значений переменной PATH обычного пользователя. Но, в конце концов, всегда можно указать полный путь к исполняемому файлу, и запустить команду
$ /usr/sbin/netpkg list
будучи простым юзером. На возможные сообщения об ошибках типа невозможности прочтения файла такого-то следует просто не обращать внимания.
Все установленные с помощью netpkg пакеты заносятся в соответствующие базы данных, общие для Slackware и ее клонов (/var/log/packages и /var/log/scripts), о которых говорилось выше. Но кроме того, netpkg ведет и собственную базу данных — её компоненты находятся в каталоге /var/netpkg/db, представляя собой набор простых текстовых файлов, в которых перечисляются установленные пакеты, списки их зависимостей, история смены текущего репозитория и так далее — заинтересованные могут просмотреть их самостоятельно, в качестве домашнего задания.
При использовании опций install и upgrade пакеты перед их установкой скачиваются из сети и помещаются в каталог /var/packages/ (как и при опции download). Кроме того, их исходники также скачиваются и попадают в каталог /usr/src, где, таким образом, оказываются исходные тексты не только ядра, как во всех остальных известных мне дистрибутивах, но и всех установленных программ.
Как обычно, с одной стороны, и то, и другое — это плюс. Случайно удаленный пакет можно восстановить из локального кэша без повторного скачивания. А наличие полного набора исходников позволяет легко пересобрать любой пакет с применени ем каких-либо специфических опций, буде в том возникнет нужда.
Но, с другой стороны, это же может быть и минусом. Ибо приводит к очень быстрому заполнению корневого каталога — если придерживаться простой схемы разметки диска, с разделами под /, swap и /home. Так, объем дискового пространства, составляющего сразу после инсталляции системы около полутора гигабайт, удваивается или даже утраивается после доустановки дополнительных пакетов и месяца регулярного использования команды netpkg upgrade при текущем snapdhot-репозитории. Причем в последнем случае и локальный кэш, и дерево исходников захламляются старыми версиями и ревизиями программ, необходимость в которых вряд ли когда-нибудь возникнет.
Средства автоматической очистки локального кэша и дерева исходников в netpkg, в отличие от apt, не предусмотрены. Соответственно, пользователю надо либо следить за этим самому, и резулярно удалять старые версии (для этого легко сочинить скрипт, который можно поместить в cron), либо отводить под / дисковый раздел с хорошим запасом. Тут поневоле с грустью вспомнишь о ZFS, поддержки которой в Linux'е так и не предвидится, и пожелаешь удачи разработчикам btrfs, также обещающим динамическое перераспределение дискового пространства... Есть еще и третий путь решения проблемы локального кэша — просто запретить его использование, что делается редактированием конфигурационного файла, о чем речь пойдет в следующем разделе.
В приведенном выше списке обращает на себя внимание также и отсутствие опций, ответственных, во-первых, за поиск пакетов, и, во-вторых, за их удаление.
В какой-то мере заменителем средств поиска могут служить фильтры, которыми являются идентификаторы статуса пакетов. Так, команда
$ netpkg list N
выведет список всех неустановленных пакетов. Однако поиск единичного пакета потребует знания хотя бы фрагмента его имени и использования внешних средств — конструкций типа
$ netpkg list | grep pkgname
поиска среди всех пакетов или
$ netpkg list N | grep pkgname
среди неустановленных.
Что же касается удаления программ, то для меня пока так и остаётся неясным вопрос — можно ли выполнить его средствами чисто консольной ипостаси netpkg? Ведь, как мы увидим дальше, в графической ипостаси этой программы (xnetpkg) такая функция присустствует. А поскольку xnetpkg вроде бы представляет собой не более чем фронт-энд над "чистой" netpkg, по идее, средство удаления должно иметься и в последней. Однако в документации упоминания о нем отсутствуют, а перебор напрашивающихся вариантов именования соответствующей опции типа remove и так далее результата не дал, как и глубокое гугление. Буду признателен, если кто-то просветит меня по этому вопросу.
В принципе, если пользоваться графической оболочкой западло, то можно удалять программы с помощью removepkg, однако тут встают все те же проблемы, которые были описаны ранее — отсутствие контроля зависимостей, легкость ошибки при удалении пакетов, от которых зависят другие. Кроме того, при этом не будут внесены изменения в базы данных собственно netpkg, и неизвестно, какие это может иметь последствия. Я такую процедуру осуществлял — и вреда не было ни малейшего, но проводилась она над пакетами с очень простыми и хорошо мне известными зависимостями.
В общем, к теме поиска и удаления пакетов нам еще придется вернуться в разделе о xnetpkg. А пока посмотрим, как осуществляется