Журнал LinuxFormat - перейти на главную

LXF125:Yum

Материал из Linuxformat
Перейти к: навигация, поиск
Подписка на печатную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подписка на электронную версию
Весь 2015 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)
Подшивки старых номеров журнала (печатные версии)
Весь 2014 год (12 номеров)
Первое полугодие (6 номеров)
Второе полугодие (6 номеров)

Содержание

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 нам в руки.

Источник — «http://wiki.linuxformat.ru/wiki/index.php?title=LXF125:Yum&oldid=11261»
Персональные инструменты
купить
подписаться
Яндекс.Метрика