Алексей Федорчук
Система PackageKit не является чем-то специфическим для дистрибутива Fedora и даже для rpm-based дистрибутивов вообще. Теоретически рассуждая, её можно прикрутить к пакетам любого формата и любым системам управления ими в любых дистрибутивах. В частности, она как дополнительная используется в Ubuntu’идах, есть примеры успешного применения её в Archlinux и даже в Gentoo.
Система PackageKit включает в себя серию бэк-эндов для работы с конкретными менеджерами пакетов (yum, apt, smart и так далее, вплоть до tar.gz). Интерфейсом к ним служит
- либо консольная утилита
pkcon, одинаковая во всех дистрибутивах и в отношении синтаксиса команд не зависящая от нижележащего пакетного менеджера, - либо графические фронт-энды, каковых минимум два — gnome-packagekit и kpackagekit, ориентированные на работу в средах GNOME/Xfce/LXDE и KDE, соответственно.
В Fedora система PackageKit появилась относительно недавно (в 9-й версии), сменив ранее бывшие штатными сладкую парочку pirut (собственно управление пакетами) и pup (тотальное обновление системы). И ныне, в текущей весии (11-й) успешно справляется с обеими задачами.
При инсталляции в Fedora по умолчанию устанавливается бэк-энд для yum, хотя в репозиториях доступны также пакеты поддержки apt и smart, консольный клиент pkcon и фронт-энд gnome-packagekit (при использовании среды KDE, надо полагать, он заменяется на kpackagekit).
Пакетные менеджеры которых имеют обычно собственный развитый инструментарий для управления пакетами из командной строки (не исключение и Fedora, как мы увидим, добравшись до yum’а). Поэтому консольная утилита pkcon представляет интерес только своей теоретической универсальностью, поскольку предполагается одинаковой в любых дистрибутивах, поддерживающих PackageKit. Так что уделим ей лишь несколько строк.
Впрочем, больше о pkcon особо и сказать нечего — её man pkcon умещается на один экран с хвостиком. Больше информации можно получить, запустив её с опцией -?, —help или без опций вообще. Ответом на что будет полный список возможных субкоманд команд и опций, правда, без всяких пояснений, так что о смысле их можно только догадываться — или искать его методом ползучего эмпиризма. Что я и предоставляю проделать заинтересованным лицам. Так что дам лишь краткую справку по тем командам, с которыми я немного разобрался.
Начнём с поиска пакетов. Команда
$ pkcon search name [package]
отыщет все пакеты, сожержащие в своём названии компонент package, краткой характеристикой, указанием номера версии и сборки, а также статуса (установлен или доступен). А командой
$ pkcon search group groupname
можно вывести список всех пакетов, входящих в группу с указанным именем.
Для установки и удаления пакетов служат команды
# pkcon install package_name
и
# pkcon remove package_name
соответственно. А команда
# pkcon update
должна выполнить тотальное обновление системы.
Как нетрудно догадаться, поиск пакетов можно выполнить, запустив pkcon от имени обычного пользователя. Но установка или удаление их потребует уже прав администратора.
Утилита pkcon не произвела на меня большого впечатления. Она кажется несколько недоработанной, хотя, возможно, я в ней просто недостаточно разобрался. Так что далее речь пойдёт исключительно о графическом фронт-энде gnome-packagekit.
Запускается эта графическая ипостась PackageKit в виде отдельного субпакета gpk-application из главного стартового меню, в зависимости от используемой среды, через пункты Приложения -> Установка и удаление программ (GNOME) или Администрирование -> Установка и удаление программ (Xfce). Причём сделать это можно от лица обычного пользователя — пароль администратора будет запрашиваться по ходу дела, при необходимости выполнения действий, требующих соответствующих полномочий. После запуска перед нами появляется окно следующего вида:
Переключаясь в левом фрейме окна на соответствующие пункты, в правом можно видеть список всех пакетов — как установленных, так и доступных в репозиториях, список коллекций, состав пакетных групп, с отметкой статуса — установлен пакет или только доступен:
Списки пакетов и коллекций можно фильтровать по:
- статусу — установлен или доступен;
- назначению — для разработчиков или конечных пользователей;
- режиму — графическому или текстовому;
- «степени свободы» — free или non-free.
По умолчанию никакая фильтрация не проводится.
Свободное поле с кнопкой Find рядом прямо так и провоцирует выполнить поиск некоего пакета. Каковой осуществляется по совпадению не только в именах пакетов, но и в их описаниях. В результате в выводе будет список всех пакетов, имеющих хоть какое-то отношение к искомому:
Поиск к регистру не чувствителен, то есть ввод packagekit и PackageKit даст одинаковый результат.
Для выделенного в правом фрейме пакета доступно его краткое описание и формальные данные — принадлежность к группе, лицензия, объем подлежащего скачиванию архива и репозиторий, из которого пакет будет получен.
Более подробную информацию о пакете можно получить через меню Selection. Так, пункт Get file lists выведет список файлов и путей к ним в том виде, в котором они будут установлены в системе:
Пункт Depends on даст список его зависимостей:
А пункт Required by — список пакетов, которые зависят от выбранного:
Для установки найденного пакета достаточно пометить его и нажать кнопку применить:
После этого некоторое время будут проверяться зависимости пакета, список которых (если они имеются и не были установлены ранее) будет выведен в специальной панели:
Нажатие кнопки Установить повлечёт за собой скачивание пакета вместе со всеми его зависимостями, из распаковку и инсталляцию. Кнопка Отмена вызовет отказ от установки не только зависимостей, но и выбранного пакета.
При первом запуске фронт-энда будет обязательно запрошен пароль администратора. В дальнейшем, отметив один из соответствующих чекбоксов, этого можно избежать навсегда или на время данного сеанса:
Если всё идёт как надо, после описанных выше манипуляций мы будем иметь в системе установленный работоспособный пакет. Что и предлагается проверить в панели сообщения об успехе инсталляции — на ней имеется кнопка Запустить, которая вызывает старт свежеустановленной программы.
Однако нельзя исключить ситуации, что в ходе проверки зависимостей будут выявлены ошибки — как правило, они связаны с конфликтом версий пакетов, от которых зависит устанавливаемый. И единственное, что можно сделать в рамках графического фронт-энда — открыть вывод More details, тупо просмотреть его и закрыть панель ошибок:
Выбранный пакет при этом, разумеется, установлен не будет — система гарантирует от инсталляции неработоспособного пакета.
Вероятно, из вывода тех самых деталей можно извлечь информацию, способствующую разрешению коллизии. Но, как мы убедимся со временем, проще в такой ситуации обратиться непосредственно к yum’у. По крайней мере, я ИМХую именно так.
Удаление пакетов происходит аналогично — только в обратном порядке:
- сначала снимается отметка с установленного пакета;
- затем нажимается кнопка Применить — и наступает ожидание проверки зависимостей, завершающееся появлением окна со списком пакетов, которые будут удалены вместе с заказанным;
- список очень внимательно изучается, после чего следует согласие на удаление или отказ от него.
Подчёркиваю необходимость очень внимательного изучения списка удаляемых зависимостей: они могут оказаться весьма неожиданными. Так, удаление пакета, установленного не индивидуально, а в составе какой-либо группы или коллекции (особенно при инсталляции), может нечувствительно вызвать снос половины системы. И потому реально заниматься удалением пакетов лучше также с помощью команд yum’а.
Да, следует добавить, что установка и удаление программ может быть выполнена и через пункты меню Selection — Install и Remove, соответственно.
Все действия по установке и удалению пакетов (а также тотальному обновлению системы, о чём будет говориться позднее) через PackageKit фиксируются в специальном лог-файле — /var/log/yum.log; как явствует из названия, он не специфичен для этой системы, а отражает действия через менеджер пакетов yum. Однако gnome-packagekit предоставляет удобную форму визуализации его содержимого, вызываемую через пункты меню Selection -> Software log. Ею выводятся: дата действия и его характер (установка, обновление или удаление), имя совершившего его пользователя и приложения (субпакета в составе gnome-packagekit, о чём будет сказано чуть позже):
Однако по хорошему, прежде чем заниматься установкой или удалением пакетов, не худо выполнить некоторые подготовительные действия.
Первое из них — проверить доступные репозитории, те самые, которые подключались на стадии установки, что делается через меню System -> Software sources. Скорее всего, все нужные источники пакетов из числа официальных для Fedora вообще и Russian Fedora в частности уже включены, но лишний раз убедиться в этом не мешает:
Разве что, при желании поразвлекаться с пересборкой пакетов, понадобиться подключить репозитории с исходниками — пакетами вида *.src.rpm. Для чего нужно отметить соответствующий чекбокс и, получив расширенный список, поставить «птицу» напротив пунктов Fedora 11 — Source и так далее:
А вот добавление репозиториев, отсутствующих в списке, то есть не официальных, — отдельная задача, которую мы будем решать иными методами, и не в этой заметке.
Закончив с репозиториями, имеет смысл обновить систему — если, конечно, число кандидатов на удаление не слишком велико, тогда, чтобы не качать лишнего, имеет смысл повременить ним до глобальной чистки.
Так или иначе, само по себе обновление выполняется через соответствующий пункт меню System — Refresh package lists, которым сначала список доступных пакетов будет приведён в актуальное (и соответствующее подключённым репозиториям) состояние, а затем будет предложен список пакетов, могущих быть обновлёнными. И, после внимательного его просмотра (или без оного) с ним остаётся только согласиться:
И теперь, если не произойдёт ошибки — обновление будет выполнено. Хотя нельзя исключить и такого исхода операции:
Особенно, если, как в приведённом выше примере, пытаться обновиться до разрабатываемой (Rawhide) версии. И в этом случае опять придётся обратиться к командной строке и запущенному в ней yum’у.
Пунктами меню Software sources и Refresh package lists вызывают самостоятельные субпакеты, входящие в gnome-packagekit — gpk-repo и gpk-update-viewer, соответственно. Но они могут быть запущены автономно, через главное стартовое меню среды — Система -> Администрирование -> Источники программ/Обновление программ. Впрочем, порядок действий в них от этого не меняется.
Из сказанного можно сделать вывод, что PackageKit в своей графической ипостаси — простое и удобное в обращении средство управления пакетами, функционально сходное с Synaptic’ом для apt. С сравнении с последним (подчеркиваю — для deb-пакетов) он производит впечатление более медлительного. Однако это связано не с ним самим, а с rpm-форматом и базами данных для yum, требующими скачивания существенно большего объёма метаинформации.
Второй же недостаток PackageKit — трудность определения причин возникновения ошибок как при установке конкретного пакета, так и тотального обновления системы. И уж полная неясность царит в вопросе, каким путём обнаружившиеся ошибки преодолевать. Это я отнёс бы к некоторой недоработанности системы PackageKit в целом — ведь по сравнению с Synaptic’ом она ещё очень молода.
Тем не менее, и в нынешнем своём виде PackageKit пригоден для повседневного использования в сфере управления пакетами, если не выходить за пределы штатных ситуаций. Когда же наступает предел его возможностям — yum нам в руки. О чём и пойдёт речь в последующих заметках.