Управление rpm-пакетами: нынче не то, что давеча

Алексей Федорчук
Впервые опубликовано: LinuxFormat, #125 (декабрь 2009)

Многие, чьё знакомство с Red Hat и его клонами пришлось на 90-е годы, надолго сохранили предубеждение и против формата их пакетов, и против утилиты управления оными. Конечно, дать команду rpm -ihv — проще, нежели собрать нужный пакет из исходников. Однако, в сравнении с портами FreeBSD, с одной стороны, и с Debian’овским APT’ом — с другой, она приобретала вид вполне бледный.

Но всё течёт, всё меняется — и ныне rpm-based дистрибутивы располагают развитыми системами пакетного менеджмента, работающими как в текстовом, так и в графическом режиме. В настоящей заметке мы остановимся на двух из них — yum и PackageKit на примере использования в дистрибутиве Fedora.

Содержание

Незнаменитый yum

Yum — система управления rpm-пакетами и их репозиториями, предлагающая автоматическую установку, обновление и удаление пакетов и пакетных групп с автоматическим контролем зависимостей. По механизму действия и функциональности она сходна с системой APT, разработанной для Debian. Однако если последний получил в последние годы широкую известность — не в последнюю очередь благодаря популярности Ubuntu, а также тому, что усилиями сначала Connectiva, а затем Altlinux широко распространился за пределами родного дистрибутива, — то yum остаётся малоизвестным.

Однако yum, с одной стороны, по своим возможностям управления rpm-пакетами ничуть не уступает утилитам семейства apt для deb-пакетов, а с другой, используется достаточно широко: эта система принята в качестве основной в Fedora, RHEL и их прямых и косвенных потомках.

Аббревиатура yum интерпретируется как Yellow dog Updater, Modified, то есть Обновитель Yellow dog Модифицированный. Однако его связь с одноимённым дистрибутивом — портом Red Hat на архитектуру Power, не совсем прямая. Его пакетный менеджер, именовавшийся YUP, послужил основой для Сета Видала (Seth Vidal), при написании yum для дистрибутива Red Hat. Символично и дословное его значение (yum — по английски конфетка) — его можно трактовать так, что эта система в состоянии сделать конфетку даже из такого… не самого приятного продукта, как пакеты в формате RPM.

Yum быстро получил признание среди ряда клонов Red Hat, в частности, был принят в качестве штатного менеджера пакетов в ASPLinux. Однако в самом Red Hat он долго конкурировал с apt-rpm, и развитие yum’а одно время только силами команды ASPLinux и осуществлялось. Однако в конце концов он утвердился в RHEL и его клонах (CentOS, Scientific Linux), в Fedora и в Yellow Dog.

Система yum включает в себя собственно одноимённую утилиту, набор дополнительных утилит (yum-utils) и многочисленные плагины, в виде самостоятельных пакетов расширяющие функциональность главной программы.

Запускается yum одноимённой командой, требующей указания субкоманды (возможно, с опциями последней), и, в ряде случаев, аргументов в виде имени пакета или группы пакетов, что в общей форме выглядит так:

$ yum subcommand [arguments] --[options]

Команда yum без указания субкоманды выведёт краткую справку касаемо последних и их опций. Аналогичный результат будет получен посредством субкоманды

$ yum help

А указание имени субкоманды в качестве аргумента, например, так

$ yum help install

выведет краткие сведения о её назначении.

Субкоманды yum’а определяют одно из действий, которое команда должна выполнить — установку или удаление пакета, вывод информации о нём, поиск пакетов и так далее. Обычно назначение субкоманды легко угадывается из её названия и (или) краткой характеристики в выводе help’а.

Все субкоманды yum можно разделить на две группы. Первая связана с поиском пакетов и получением информации о них, вторая — с манипуляциями пакетами и группами.

В составы первой группы наиболее употребимы:

search [string] — поиск пакета по имени или его фрагменту;
list — вывод списка пакетов, всех (all или без указания фильтра), установленных (installed) или доступных (available);
info pkgname — вывод полной информации о пакете.

Все субкоманды первой группы могут исполняться от лица обычного пользователя.

Во второй группе субкоманд наиболее важны:

install pkgname1 ... pkgname# — установка из репозиториев единичного пакета или нескольких пакетов, имена которых даны (в краткой форме) в качестве аргумента, вместе со всеми их зависимостями;
localinstall path2/fullname.rpm — установка пакета из локально хранящегося файла; зависимости его извлекаются из репозиториев, если таковые доступны;
update [pkgname] — обновление пакета, указанного в качестве аргумента; в отсутствие аргумента выполняется тотальное обновление системы, аналогично сумме apt-get update и apt-get upgrade;
erase pkgname — удаление пакета вместе со всем, что от него зависит; пакеты, от которых зависит удаляемый, остаются в неприкосновенности, даже если они никем не используются.

Все субкоманды второй группы для своего исполнения требуют прав администратора.

Отдельно надо сказать о субкоманде shell — она запускает собственную интерактивную командную оболочку yum’а, в сеансе которой можно оперировать уже просто его субкомандами, аргументами и опциями, пуская главную команду yum.

Рис. 1. Yum с его интерактивной оболочкой

Исполнение любой субкоманды начинается с синхронизации локальной базы пакетов с базами репозиториев. Затем происходит проверка зависимостей — и по её результатам выводится итог: сколько пакетов, включая зависимости, должно быть установлено, обновлено или удалено, их имена, подлежащий скачиванию объем информации. И запрашивается подтверждением на выполнение операции.

Опции yum довольно многочисленны, привязаны как к главной команде, так и к отдельным субкомандам. Исчерпывающую справку о них можно получить через

$ man (8) yum

В состав пакета yum-utils входит серия утилит, запускаемых как самостоятельные команды, со своими опциями. Полный их список можно получить из

$ man yum-utils

Важнейшей из этих команд является package-cleanup, предназначенная для получения сведений о непорядках в локальной базе данных пакетов и их устранения. Она имеет несколько опций. Например,

$ package-cleanup --problems

выведет список нарушенных зависимостей, а с помощью команды

$ package-cleanup --leaves

можно вывести список пакетов, от которых не зависят никакие другие компоненты.

Плагины, в отличие от утилит, не запускаются как самостоятельные команды, а встраиваются по умолчанию в команду yum, добавляя ей новые функции. По умолчанию в RFRemix устанавливаются следующие плагины:

fastestmirror — проверка скорости доступа к зеркалам репозитория и выбор самого быстрого из них, выполняется при каждом запуске команды yum;
presto — при обновлении пакетов скачивает из репозиториев только дельты изменений (deltarpms), минимизируя таким образом трафик;
refresh-packagekit — обеспечивает обновление системы PackageKit.

Эффективное использование yum требует некоторых мероприятий по настройке, включающих:

настройку собственно yum;
подключение и настройку плагинов;
подключение дополнительных репозиториев.

За настройки собственно yum отвечает файл /etc/yum.conf — он содержит общие параметры для этой утилиты в формате:

название=значение

Значение может быть булевым (0 — запрещено, 1 — разрешено), численным — от 1 и до… разумного предела (значение 0 равносильно отключению) или символьным — например, путь к каталогу или список пакетов; в последнем случае значения разделяются пробелами. По умолчанию yum.conf выглядит так:

cachedir=/var/cache/yum — каталог для кэширования метаданных репозиториев и пакетов, скачиваемых в ходе установки ;
keepcache=0 — определяет, сохранять ли скачанные пакеты в локальном кэше или удалять их после успешной установки;
debuglevel=2 — уровень отладочных сообщений;
logfile=/var/log/yum.log — каталог для файлов протоколирования действий yum;
exactarch=1 — значение по умолчанию предписывает устанавливать пакеты, точно соответствующие архитектуре;
obsoletes=1 — определяет логику замены “устаревших” пакетов при тотальном обновлении;
gpgcheck=1 — включение этой опции обязывает к проверке подписей при установке;
plugins=1 — использовать или нет плагины к yum’у;
installonly_limit=3 — максимальное количество пакетов, запрещённых к обновлению (можно только устанавливать параллельно более новую версию).

Кроме перечисленных, существует ещё немало параметров настройки yum. Так, очевидно, что опция installonly_limit имеет смысл только при наличии списка запрещённых к обновлению пакетов. Он задаётся параметром

installonlypkgs=pkgname1 pkgname2 ... pkgname#

Есть возможность и задать список пакетов, для которых запрещено как обновление, так и инсталляция, что иногда требуется при использовании проприетарных пакетов:

exclude=pkgname1 pkgname2 ... pkgname#

Полезной может оказаться параметр skip_broken — он заставляет пропускать установку пакетов с нарушенными зависимостями.
Параметр recent нужен для субкоманды list с одноимённой опцией: он устанавливает срок, в течении которого добавленные в репозиторий пакеты считать новыми.

Что очень раздражает в yum — это синхронизация метаданных о репозиториях, происходящая каждый раз при его запуске с любой субкомандой — даже от лица пользователя, когда реально кэш метаданных обновлён быть не может. Такая ситуация изменяется параметром metadata_expire, которому можно дать то значение, которое покажется разумным. Или вписать строку

metadata_expire=never

И тогда обновление кэша метаданных будет производиться только по запросу.

Обратимся к плагинам. Они устанавливаются точно так же, как и любые другие пакеты. Соответствующие каждому из установленных плагинов конфигурационные файлы располагаются в каталоге /etc/yum/pluginconf.d и имеют имена, по которым легко догадаться, к какому из плагинов относится любой конфиг.

Большинство плагинных конфигов предельно просто и содержит единственную строку, разрешающую его подключение:

enabled=1

В конфиге плагина presto можно запретить локальное кэширование дельт, раскомментировав параметр

keepdeltas = false

А можно определить, что же считать дельтой. Например, параметр

minimum_percentage = 95

указывает, что если изменённая часть пакета составляет 95% или менее от цельного, то будет скачиваться она, если же больше — загрузится пакет целиком.

Чтобы настраивать параметры доступа к репозиториям, их необходимо сначала подключить. Подключение “левых” репозиториев не сложно: вся метаинформация о любом репозитории, пригодном для эксплуатации yum’ом, собрана в виде обычного rpm-пакета, который может быть обычным же образом установлен. Вся загвоздка в том, что пакет этот хранится внутри собственного, ещё не подключённого, репозитория, и потому yum’ом установлен быть не может.

Так что нам придётся добраться до нужного пакета, описывающего репозиторий, в Сети, скачать его, установить с помощью команды rpm, а затем уже обеспечить доступность репозитория.

Рассмотрим эту процедуру на примере подключения репозитория для пакетов флэш-плейера. Для этого заходим на официальный сайт Adobe, в пункте Download отыскиваем строку Get flash player, и из выпадающего списка Select version to download… выбираем YUM for Linux, каковой (в виде файла adobe-release-i386-1.0-1.noarch.rpm) и скачиваем. Затем даём команду

# rpm -Uhv adobe-release-i386-1.0-1.noarch.rpm

По её успешном исполнении в каталоге с конфигами репозиториев можно будет увидеть новый файл adobe-linux-i386.repo. Одновременно он станет доступным для обновляющих манипуляций командой

# yum update

Подключить новый репозиторий можно и совсем вручную. Проделаем эту операцию для репозитория (почти) ежедневных сборок браузера Chromium от Тома Колловея: создадим в каталоге /etc/yum.repos.d файл chromium.repo и впишем в него такие строки:

[chromium]
name=Google Chrome
baseurl=http://spot.fedorapeople.org/chromium/F$releasever/
nabled=1
gpgcheck=0

Надеюсь, мне удалось показать, что yum делает употребление rpm-пакетов абсолютно безвредным. В случае же напряжённых отношений с командной строкой для управления rpm-пакетами можно обратиться к графической утилите PackageKit, речь о которой пойдёт в следующем разделе.

PackageKit — кит пакетного менеджмента

Если yum всегда оставался в тени Debian’овского APT’а, то о графической надстройке PackageKit говорят ещё меньше. Хотя она не является чем-то специфическим для rpm-based дистрибутивов: её можно прикрутить к пакетам любого формата в любых дистрибутивах, вплоть до Archlinux и Gentoo.

Система PackageKit распадается на серию бэк-эндов для работы с конкретными менеджерами пакетов и интерфейсные надстройки.
Бэк-энды PackageKit предполагают работу с такими системами, как yum, apt, smart и так далее, вплоть до pacman. Интерфейсом к ним служат

либо консольная утилита pkcon, одинаковая во всех дистрибутивах и в отношении синтаксиса команд не зависящая от нижележащего пакетного менеджера,
либо графические фронт-энды, каковых минимум два — gnome-packagekit и kpackagekit, ориентированные на работу в средах GNOME/Xfce/LXDE и KDE, соответственно.

При инсталляции в Fedora по умолчанию устанавливается бэк-энд для yum и фронт-энд gnome-packagekit (при выборе в качестве рабочей среды KDE он заменяется на kpackagekit). Но в репозиториях доступны пакеты поддержки apt и smart, а также консольный клиент pkcon.

Пакетные менеджеры, поддерживаемые системой PackageKit, имеют обычно собственный развитый инструментарий для управления пакетами из командной строки (не исключение и Fedora, как мы видели в заметке про yum). Поэтому консольная утилита pkcon представляет интерес только своей теоретической универсальностью — она одинакова в любых дистрибутивах, поддерживающих PackageKit, так что задерживаться на ней не будем.

Графическая ипостась PackageKit в виде субпакета gpk-application запускается из главного стартового меню, в зависимости от используемой среды, через пункты Приложения -> Установка и удаление программ (GNOME) или Администрирование -> Установка и удаление программ (Xfce). Причём сделать это можно от лица обычного пользователя — пароль администратора будет запрашиваться по ходу дела, при необходимости выполнения действий, требующих соответствующих полномочий. После запуска перед нами появляется окно следующего вида:

Рис. 2. PackageKit — общий вид

Переключаясь в левом фрейме окна на соответствующие пункты, в правом можно видеть список всех пакетов — как установленных, так и доступных в репозиториях. Списки пакетов и коллекций можно фильтровать по:

статусу — установлен или доступен;
назначению — для разработчиков или конечных пользователей;
режиму — графическому или текстовому;
“степени свободы” — free или non-free.

По умолчанию никакая фильтрация не проводится.

Свободное поле с кнопкой Find рядом прямо так и провоцирует выполнить поиск некоего пакета. Каковой осуществляется по совпадению (не чувствительно к регистру) не только в именах пакетов, но и в их описаниях. В результате в выводе будет список всех пакетов, имеющих хоть какое-то отношение к искомому.

Для выделенного пакета доступно его краткое описание и формальные данные — принадлежность к группе, лицензия, объем подлежащего скачиванию архива и репозиторий, из которого пакет будет получен.

Более подробную информацию о пакете можно получить через меню Selection. Так, пункт Get file lists выведет список файлов и путей к ним в том виде, в котором они будут установлены в системе. Пункт Depends on даст список его зависимостей. А пункт Required by — список пакетов, которые зависят от выбранного.

Для установки найденного пакета достаточно пометить его и нажать кнопку Применить. После этого некоторое время будут проверяться зависимости пакета, список которых выводится в специальной панели.

Рис. 3. Вывод списка зависимых пакетов

Нажатие кнопки Установить повлечёт за собой скачивание пакета вместе со всеми его зависимостями, из распаковку и инсталляцию. Кнопка Отмена вызовет отказ от установки не только зависимостей, но и выбранного пакета.

Если всё идёт как надо, после описанных выше манипуляций мы будем иметь в системе установленный работоспособный пакет. Что и предлагается проверить в панели сообщения об успехе инсталляции — на ней имеется кнопка Запустить, которая вызывает старт свежеустановленной программы.

Однако нельзя исключить ситуации, что в ходе проверки зависимостей будут выявлены ошибки — как правило, они связаны с конфликтом версий пакетов, от которых зависит устанавливаемый. И единственное, что тут можно сделать — открыть вывод More details, тупо просмотреть его и закрыть панель ошибок. Выбранный пакет при этом, разумеется, установлен не будет.

Удаление пакетов происходит аналогично — только в обратном порядке:

сначала снимается отметка с установленного пакета;
затем нажимается кнопка Применить — и наступает ожидание проверки зависимостей, завершающееся появлением окна со списком пакетов, которые будут удалены вместе с заказанным;
список очень внимательно изучается, после чего следует согласие на удаление или отказ от него.

Подчёркиваю необходимость очень внимательного изучения списка удаляемых зависимостей: они могут оказаться весьма неожиданными. Так, удаление пакета, установленного не индивидуально, а в составе какой-либо группы или коллекции (особенно при инсталляции), может нечувствительно вызвать снос половины системы.

PackageKit в 12-й версии Fedora получит (за счёт отдельных плагинов) такие дополнительные возможности, как автоматическая установка пакетов по щелчку на имени файла в браузере или из командной строки — в ответ на сообщение

command not found

Все действия по установке и удалению пакетов (а также тотальному обновлению системы, о чём будет говориться позднее) через PackageKit фиксируются в специальном лог-файле — /var/log/yum.log; как явствует из названия, он не специфичен для этой системы, а отражает действия через менеджер пакетов yum. Однако gnome-packagekit предоставляет удобную форму визуализации его содержимого, вызываемую через пункты меню System -> Software log, где показываются: дата действия и его характер (установка, обновление или удаление), имя совершившего его пользователя и приложения (субпакета в составе gnome-packagekit):

Рис. 4. Журнал установки, обновления и удаления пакетов

Однако по хорошему, прежде чем заниматься установкой или удалением пакетов, не худо выполнить некоторые подготовительные действия.
Первое из них — проверить доступные репозитории, те самые, которые подключались на стадии установки, что делается через меню System -> Software source. Скорее всего, все нужные источники пакетов из числа официальных для Fedora вообще и Russian Fedora в частности уже включены, но лишний раз убедиться в этом не мешает.

Затем имеет смысл обновить систему — через пункт меню System -> Refresh package lists, который сначала приведёт список доступных пакетов в актуальное (и соответствующее подключённым репозиториям) состояние, а затем предложит список пакетов, могущих быть обновлёнными, с которым остаётся только согласиться.

И теперь обновление будет выполнено, если не произойдёт ошибки —. хотя нельзя исключить и последнего варианта. В этом случае придётся обратиться к командной строке и yum’у.

Пунктами меню Software source и Refresh package lists вызывают самостоятельные субпакеты, входящие в gnome-packagekit — gpk-repo и gpk-update-viewer, соответственно. Но они могут быть запущены автономно, через главное стартовое меню среды — Система -> Администрирование -> Источники программ/Обновление программ.

Из сказанного можно сделать вывод, что PackageKit в своей графической ипостаси — простое и удобное в обращении средство управления пакетами, функционально сходное с Synaptic’ом для deb-пакетов. В сравнении с последним он производит впечатление более медлительного. Однако это связано не с ним самим, а с rpm-форматом и базами данных для yum, требующими скачивания существенно большего объёма метаинформации.

Второй недостаток PackageKit — трудность определения причин возникновения ошибок как при установке конкретного пакета, так и тотального обновления системы. Это я отнёс бы к некоторой недоработанности системы PackageKit в целом — ведь по сравнению с Synaptic’ом она ещё очень молода.

Однако и в нынешнем своём виде PackageKit пригоден для повседневного использования в сфере управления пакетами, если не выходить за пределы штатных ситуаций — при их возникновении yum нам в руки.