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

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

Yum — система управления RPM-пакетами и их репозиториями, предлагающая автоматическую установку, обновление и удаление пакетов и пакетных групп с контролем зависимостей. По механизму действия и функциональности она сходна с APT. Однако если последний получил широкую известность — не в последнюю очередь благодаря популярности Ubuntu, а также тому, что усилиями сначала Connective, а затем ALT Linux широко распространился за пределами родного дистрибутива, то Yum остается сравнительно малоизвестным.

По своим возможностям Yum для RPM ничуть не уступает утилитам APT для Deb, и используется достаточно широко: эта система принята в качестве основной в Fedora, RHEL и их прямых и косвенных потомках

Yum означает Yellow Dog Updater, Modified, то есть Обновитель Yellow Dog Модифицированный. Однако его связь с одноименным дистрибутивом — портом Red Hat на архитектуру Power PC — не совсем прямая. Просто пакетный менеджер Yellow Dog, 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.baseurl.org) включает собственно одноименную утилиту, набор дополнительных инструментов (yum-utils) и многочисленные дополнения, расширяющие функциональность основной программы.

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

yum subcommand [arguments] --[options]

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

yum help

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

yum help install

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

Азбука сиинтаксиса

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

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

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

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

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

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

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

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

Отдельно надо сказать о субкоманде shell — она запускает собственную интерактивную командную оболочку Yum, в сеансе которой можно оперировать субкомандами, аргументами и опциями, опуская главную команду 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;
• подбор и настройку дополнений;
• подключение дополнительных репозиториев.

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

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

• cachedir=/var/cache/yum Каталог для кэширования метаданных репозиториев и пакетов, скачиваемых входе установки.
• keepcache=0 Определяет, сохранять ли скачанные пакеты в локальном кэше или удалять их после успешной установки.
• debuglevel=2 Уровень отладочных сообщений.
• logfile=/var/log/yum.log Каталог для файлов протоколирования действий Yum.
• exactarch=1 Устанавливать пакеты, точно соответствующие архитектуре.
• obsoletes=1 Определяет логику замены «устаревших» пакетов при тотальном обновлении.
• gpgcheck=1 Проверять подписи пакетов при установке. plugins=1 Использовать дополнения. installonly_limit=3 Максимальное количество пакетов, запрещенных к обновлению (можно только устанавливать более новую версию параллельно).

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

installonly_pkgs=пакет1 пакет2 ...

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

Полезным может оказаться 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 Flash. Для этого заходим на официальный сайт Adobe, на первом шаге выбираем ОС Linux, на втором Flash Player for other Linux (YUM) и скачиваем (в виде файла adobe-release-i386-1.0-1.noarch). Затем даем команду

rpm -Uvh adobe-release-i386-1.0-1.noarch

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

yum update

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

[fedora-chromium]
name=Chromium web browser and deps (trunk checkout)
baseurl=http://repos.fedorapeople.org/repos/spot/chromium/fedora-$releasever/$basearch/
enabled=1
gpgcheck=0

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