При удалении пакетов с помощью removepkg никакой контроль зависимостей, как и следует ожидать, не производится. То есть удалять пакеты, установленные только как зависимости данного и нигде более не используемые, придется вручную. Но это еще полбеды: с помощью removepkg можно спокойно удалить библиотечный пакет, от которого зависят другие пакеты, приведя, тем самым, последние в неработоспособное состояние. Иными словами, посредством removepkg можно добиться ничуть не менее превосходного результата по выведению системы из строя, чем знаменитой командой
Сведения об удаленных пакетах заносятся в собственную базу данных — /var/log/removed-packages/, а о соответствующих им скриптах — в каталог /var/log/removed-scripts, которые устроены точно также, как и базы для установленных пакетов. В базе удаленных пакетов фиксируются и сведения о пакетах, подвернувшихся апгрейду (в результате использования утилиты upgradepkg или посредством системы пакетного менеджмента).
Команда такого вида отыщет в каталоге /var/log/packages/ файл, соответствующий пакету jed, определит из него пофайловый состав пакета и удалит все компоненты из соответствующих подкаталогов. При этом настроечные файлы пользователя, хранящиеся в его домашнем каталоге (файлы вида ~/.pkg_namerc и подобные, именуемые также dot-файлами), сохранятся. Избавиться от них (если это нужно) можно будет только вручную.
Утилита removepkg, как нетрудно догадаться, отвечает за удаление ранее установленных программ. В качестве аргумента она требует только краткого имени (basename) удаляемого пакета, например:
Утилита upgradepkg, как следует из её названия, выполняет обновление ранее установленного пакета до новой версии. Эта процедура заключается просто-напросто в удалении файлов старой версии и помещении на их место соответствующих новых комопнентов, хотя тут возможны ньюансы, с которыми можно ознакомиться на man-странице утилиты. Теоретически при этом конфигурационные файлы старой версии сохраняются, однако одноименная man-страница рекомендует сохранить их во избежание неприятностей.
Собственно, назначение утилиты explodepkg чисто образовательное — с её помощью можно изучить состав пакета и его структуру. Это особенно важно, если устанавливать в Zenwalk'е пакеты, собранные для Slackware или иных её клонов: из-за временами возникающих различий в файловой иерархии между дистрибутивами Slackware-based (например, использовании или неиспользовании каталога /opt) компоненты пакета могут оказаться не совсем там, где это ожидалось.
Утилита explodepkg имеет своей целью просто распаковку пакета в текущий каталог. Аргументом её также служит имя пакета в полной форме и путь к нему. При использовании этой утилиты следует помнить, что она полагает текущий каталог корневым в системе и, соответственно, помещает извлекаемые компоненты пакета в подкаталоги типа usr/bin, /usr/share и так далее. То есть запуская explodepkg из домашнего каталога, мы получим в нём много хлама.
Тем не менее, для установки единичных пакетов с простыми (или хорошо известными) зависимостями использование installpkg — самый прямой путь. Однако не советую ступать на него при установке, скажем, KDE — развлечение вам будет гарантировано надолго.
Если же мы попытаемся тем же образом установить пакет, зависящий от каких-либо отсутствующих библиотек, то никаких сообщений об ошибках не последует, и, более того, исполняемый файл пакета обнаружится на месте (например, в /usr/bin). Однако запустить его не удастся: уж тут-то последует сообщение об ошибках, связанных с отстутствием таких-то и таких-то библиотечных файлов. Заметьте, файлов — а не библиотечных пакетов, эти файлы содержащих. Так что вычислить зависимости по таким сообщениям окажется задачей, не вполне тривиальной.
Возвращаясь к installpkg, заметим, что с его помощью пакет будет установлен (то есть распакован и включён в файловую иерархию) в любом случае. Другой вопрос, будет ли он работать. Приведенный на рис. 9.03 пример с текстовым редактором jed имеет благоприятный исход: в зависимостях этого пакета значатся gpm и slang, которые ранее в системе были установлены, и потому jed заработает без проблем.
и так далее. Обращаем внимание, что в этом списке содержатся файлы только самого авторского пакета, тогда как в его архиве имелись и установочные скрипты (атрибут только пакетов Slackware). Скрипты эти при установке попадают в самостоятельный каталог — /var/log/scripts. Вся эта информация будет затребована при удалении пакета, если в этом возникнет необходимость.
Сведения об установленных пакетах содержатся в одноименных им файлах вида pkg_name-version-architecture-revision. Это простые текстовые файлы, содержащие, во-первых, описание пакета, а во-вторых (и это самое главное), список всех его компонентов с указанием полных путей, отсчитываемых от корневого каталога, примерно в таком виде
Это означает, что пакет был благополучно установлен, и сведения о нем занесены в базу данных установленных пакетов, каковая имеет место быть в каталоге /var/log/packages/, куда попадают данные о всех пакетах, установленных штатным образом — с дистрибутивного носителя при первичной установке системы, с помощью средств установки или пакетного менеджера.
Рис. 9.03. Установка пакета с помощью installpkg
Назначение их более или менее понятно из названий. Так, installpkg — это средство для установки единичного пакета. Оно требует в качестве аргумента имени файла устанавливаемого пакета (в полной форме, включая номер версии, сборки, архитектуру и суффикс) и пути к нему. После запуска такой командной директивы (разумеется, команда должны выполняться от лица администратора) выводится описание пакета, сообщение о запуске инсталляционного скрипта, и возвращается приглашение командной строки (рис. 9.03).
Для манипулирования единичными пакетами в Zemwalk имеется комплекс утилит, унаследованных от Slackware: installpkg, explodepkg, upgradepkg, removepkg, makepkg.
Средства установки пакетов
ZenwalkПриобщение к Linux
Последние комментарии
Zenwalk Приобщение к Linux
Комментариев нет:
Отправить комментарий