- Подписка на печатную версию:
- Подписка на электронную версию:
- Подшивки старых номеров журнала (печатные версии)
LXF125:Yum
Материал из Linuxformat.
Содержание |
RPM:Нынче не то, что давеча
- Если вы до сих пор считаете RPM пакетной системой второго сорта, Алексей Федорчук попробует переубедить вас, заодно затронув новое веяние в этой области – PackageKit.
Многие, чье знакомство с Red Hat и его клонами пришлось на 90-е годы, надолго сохранили предубеждение и против формата их пакетов, и против утилиты управления оными. Конечно, написать rpm -ihv проще, нежели собрать нужный пакет из исходников. Однако в сравнении с портами FreeBSD с одной стороны и APT от Debian с другой, это выглядело бледно. Но все течет, все меняется – и ныне RPM-дистрибутивы располагают развитыми системами пакетного менеджмента, работающими как в текстовом, так и в графическом режиме. В настоящей статье мы оста новимся на двух из них – Yum и PackageKit – на примере дистрибутива Fedora.
Часть 1: Незнаменитый Yum
Yum – система управления RPM-пакетами и их репозиториями, предлагающая автоматическую установку, обновление и удаление пакетов и пакетных групп с контролем зависимостей. По механизму действия и функциональности она сходна с APT. Однако если последний получил широкую известность – не в последнюю очередь благодаря популярности Ubuntu, а также тому, что усилиями сначала Connectiva, а затем 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 (http://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 имеет смысл только при наличии списка запрещенных к обновлению пакетов. Он задается параметром
installonlypkgs=пакет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 (http://www.adobe.com), в пункте 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 от Тома Коллуэея [Tom Callaway]: создадим в каталоге /etc/yum.repos.d файл chromium.repo и впишем в него такие строки:
[chromium] name=Google Chrome baseurl=http://spot.fedorapeople.org/chromium/F$releasever/ enabled=1 gpgcheck=0
Надеюсь, мне удалось показать, что Yum делает употребление RPM-пакетов абсолютно безвредным. В случае же напряженных отношений с командной строкой для управления RPM-пакетами можно обратиться к графической утилите PackageKit, к которой мы и переходим.
Часть 2: PackageKit – кит пакетного менеджмента
Если Yum всегда оставался в тени APT, то о надстройке PackageKit (http://www.packagekot.org) говорят еще меньше. Хотя она не является чем-то специфическим для RPM-дистрибутивов: ее можно приспособить к чему угодно и любым Linux-системам, вплоть до Arch и Gentoo.
Система PackageKit распадается на серию «драйверов» [back-end] для работы с конкретными менеджерами пакетов и интерфейсные надстройки. Драйверы PackageKit поддерживают такие инструменты, как Yum, APT, Smart и так далее, вплоть до Pacman. Интерфейсом к ним служат либо консольная утилита pkcon, одинаковая во всех дистрибутивах и в отношении синтаксиса команд не зависящая от нижележащего пакетного менеджера, либо графические оболочки gnome-packagekit и KPackageKit для Gnome и KDE соответственно.
При инсталляции в Fedora по умолчанию устанавливается драйвер для Yum и оболочка gnome-packagekit (при выборе в качестве рабочей среды KDE он заменяется на KPackageKit). В репозиториях доступны пакеты поддержки APT и Smart, а также консольный клиент pkcon.
Пакетные менеджеры, поддерживаемые системой PackageKit, имеют обычно собственный развитый инструментарий для управления пакетами из командной строки (Yum и Fedora, как мы видели, не исключение). Поэтому консольная утилита pkcon представляет интерес только своей теоретической универсальностью – она одинакова во всех дистрибутивах, поддерживающих PackageKit; так что задерживаться на ней не будем.
Приятный интерфейс
Графическая ипостась PackageKit в виде субпакета gpk-application запускается из стартового меню, в зависимости от используемой среды, через пункты Приложения > Установка и удаление программ (Gnome) или Администрирование > Установка и удаление программ (Xfce). Причем сделать это можно от лица обычного пользователя – пароль администратора будет запрашиваться по ходу дела, при необходимости выполнения действий, требующих соответствующих полномочий. После запуска перед нами появляется окно, показанное на рисунке.
Переключаясь на соответствующие пункты в левой части, в правой вы будете видеть список всех пакетов – как установленных, так и доступных в репозиториях. Списки пакетов и коллекций можно фильтровать по статусу (установлен или доступен), назначению (для разработчиков или конечных пользователей), режиму (графический или текстовый) и степени свободы (free или non-free). По умолчанию никакая фильтрация не производится.
Свободное поле с кнопкой Find [Поиск] рядом прямо так и провоцирует выполнить поиск некоего пакета. Он осуществляется по совпадению (нечувствительно к регистру) не только в именах пакетов, но и в их описаниях. В результате в выводе будет список всех пакетов, имеющих хоть какое-то отношение к искомому.
Для выделенного пакета доступно его краткое описание и формальные данные – принадлежность к группе, лицензия, объем подлежащего скачиванию архива и репозиторий, из которого будет получен пакет.
Более подробную информацию о пакете можно получить через меню Selection [Выделение]. Так, пункт Get file lists [Списки файлов] выведет список файлов и путей к ним в том виде, в котором они будут установлены в системе. Пункт Depends on [Зависит от] даст список зависимостей пакета, а Required by [Требуется] – список пакетов, которые зависят от выбранного.
Для установки найденного пакета достаточно пометить его и нажать кнопку Apply [Применить]. После этого некоторое время будут проверяться зависимости пакета, список которых выводится в специальной панели.
Нажатие кнопки Install [Установить] повлечет за собой скачивание пакета вместе со всеми его зависимостями, их распаковку и инсталляцию. Кнопка Cancel [Отмена] вызовет отказ от установки не только зависимостей, но и выбранного пакета.
Если все идет как надо, после описанных выше манипуляций мы будем иметь в системе установленный работоспособный пакет. Что и предлагается проверить в панели сообщения об успехе инсталляции – на ней имеется кнопка Run [Запустить], которая вызывает старт свежеустановленной программы.
Однако нельзя исключить ситуации, что в ходе проверки зависимостей будут выявлены ошибки – как правило, они связаны с конфликтом версий пакетов, от которых зависит устанавливаемый. И единственное, что тут можно сделать – открыть вывод More details [Подробности], просмотреть его и закрыть панель ошибок. Выбранный пакет при этом, разумеется, установлен не будет.
Удаление пакетов происходит аналогично, только в обратном порядке: сначала снимается отметка с установленного пакета, затем нажимается кнопка Apply [Применить] – и наступает ожидание проверки зависимостей, завершающееся появлением окна со списком пакетов, которые будут удалены вместе с заказанным. Список очень внимательно изучается, после чего следует согласие на удаление или отказ от него.
Подчеркну необходимость очень внимательного изучения списка удаляемых зависимостей: они могут оказаться весьма неожиданными. Так, удаление пакета, установленного не индивидуально, а в составе какой-либо группы или коллекции (особенно при инсталляции), может нечаянно повлечь за собой снос половины системы.
PackageKit в Fedora 12 получит (за счет отдельных расширений) такие дополнительные возможности, как автоматическая установка пакетов по щелчку на имени файла в браузере или из командной строки – в ответ на сообщение «command not found».
Все действия по установке и удалению пакетов через PackageKit фиксируются в специальном файле – /var/log/yum.log; как явствует из названия, он не специфичен для PackageKit, а отражает действия через менеджер пакетов Yum. Однако gnome-packagekit предоставляет удобную форму визуализации его содержимого, вызываемую через пункты меню System > Software log [Система > Журнал установки], где показываются: дата действия и его характер (установка, обновление или удаление), имя совершившего его пользователя и приложения (субпакета в составе gnome-packagekit).
По-хорошему, прежде чем заниматься установкой или удалением пакетов, неплохо бы выполнить некоторые подготовительные действия.
Во-первых, надо проверить доступные репозитории (те самые, которые подключались на стадии установки), что делается через меню System > Software sources [Система > Источники программ]. Скорее всего, все нужные источники пакетов из числа официальных для Fedora вообще и Russian Fedora в частности уже включены, но лишний раз убедиться в этом не мешает.
Затем имеет смысл обновить систему – через пункт меню System > Refresh package lists [Система > Обновление списка пакетов], который сначала приведет список доступных пакетов в актуальное (и соответствующее подключенным репозиториям) состояние, а затем предложит список пакетов, могущих быть обновленными, с которым остается только согласиться. И теперь обновление будет выполнено, если не произойдет ошибки – хотя нельзя исключить и последнего варианта. В этом случае придется обратиться к командной строке и Yum.
Пункты меню Software sources [Источники программ] и Refresh package lists [Обновление списка пакетов] вызывают самостоятельные субпакеты, входящие в gnome-packagekit – gpk-repo и gpk-update-viewer, соответственно. Но они могут быть запущены автономно, через главное стартовое меню среды – Система > Администрирование > Источники программ/Обновление программ.
Резюме
Из сказанного можно сделать вывод, что PackageKit в своей графической ипостаси – простое и удобное в обращении средство управления пакетами, функционально сходное с Synaptic для Deb-пакетов. В сравнении с последним он производит впечатление более медлительного. Однако это связано не с ним самим, а с RPM-форматом и базами данных для Yum, требующими скачивания существенно большего объема метаинформации. Второй недостаток PackageKit – трудность определения причин возникновения ошибок как при установке конкретного пакета, так и при тотальном обновлении системы. Это я отнес бы к некоторой недоработанности системы PackageKit в целом – ведь по сравнению с Synaptic она еще очень молода.
Однако и в своем нынешнем виде PackageKit пригоден для повседневного использования в сфере управления пакетами, если не выходить за пределы штатных ситуаций – а при их возникновении Yum нам в руки.