Fedora: управление пакетами. Система YUM

Алексей Федорчук

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

Система YUM и утилита yum

Для начала мы ознакомимся, что же такое YUM вообще. Тут перво-напрево, надо помнить, что существует система YUM и утилита yum. Здесь и далее верхний регистр будет использоваться применительно к первой, нижний — ко второй. На ближайших страницах будут даны общие сведения о той и о другой.

Система YUM. Введение

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

По механизму действия и функциональности система YUM сходна с системой APT, используемой в Debian и его производных. Однако, если APT представляет собой набор утилит командной строки разного назначения (apt-get, apt-cache и так далее), то система YUM — это самодостаточная одноимённая команда, функции которой определяются указанием специальных субкоманд. Связанные же с ней дополнительные утилиты (yum-utils) предназначены для выполнения вспомогательных действий. Кроме того, возможности <code>yum</code> могут быть расширены за счёт дополнительных модулей (плагинов). Наконец, эта утилита имеет собственную командную оболочку (yum shell).

Не меньше сходства обнаруживает YUM и с aptitude из того же Debian’а, если та запущена в командном режиме. Однако, в отличие от последней, интерактивного режима <code>yum</code> не имеет. Правда, для него разработано несколько графических оболочек, в частности yumex (Yum Extender graphical package management tool).

Система YUM используется в Fedora в качестве пакетного менеджера по умолчанию с самых первых дней её существования, начавшегося релизом 1 в ноябре 2003 года, и разивтие её неразрывно связано с этим дистрибутивом. Поэтому знакомство с YUM мы начнём с исторического экскурса.

Система YUM. История

Аббревиатура YUM интерпретируется как Yellow dog Updater, Modified, то есть Обновитель Yellow dog Модифицированный. Что заставляет предполагать его связь с одноимённым дистрибутивом — портом Red Hat на архитектуру Power.
Связь между YUM и Yellow dog действительно есть, хотя и не совсем прямая. В Yellow dog использовался свой пакетный менеджер, именовавшийся YUP, написанный Брайаном Стиллвелом (Bryan Stillwell) сотоварищи в 1999 году. За пределы родного дистрибутива он не вышел, но послужил прототипом для героя нашего повествования.

В том же 1999 году на физический факультет Университета Дюка (Duke University Physics Durham, NC) приходит Сет Видал (Seth Vidal) — чтобы работать там… нет, не крокодилом, а системным администратором. И админил ни что иное, как машины с Red Hat. Каковой, при всех его уже тогда общепризнанных достоинствах, явно отставал по части пакетного менеджмента — весна 1999 года была началом грядущего победного шествия системы APT в Debian.

Систему APT быстро оценили за пределами родного дистрибутива, и вскоре усилиями бразильской фирмы Conectiva она была адаптирована для работы с пакетами rpm-формата под именем apt-rpm. Однако Сет пошёл другим путём.

Взяв за основу YUP из Yellow dog, каковой изначально разрабатывался для управления rpm-пакетами, он вместе с Майклом Стеннером (Michael Stenner) и другими коллегами (все они, вместе с разработчиками первозданного YUP, поимённо перечислены в файле /usr/share/doc/yum-3.2.28/AUTHOR;, который, с поправкой на номер версии, можно найти в любой установленной Fedora) практически полностью перепил его, приспособив для использования в дистрибутиве Red Hat. Новая система пакетного менеджмента и получила имя YUM.

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

Однако вернёмся к истории. Судя по архиву проекта YUM впервые стал общедоступным (в версии 0.8.0) в июне 2002 года. А в сентябре того же года он в качестве штатного менеджера пакетов появляется… нет, не в Red Hat, как можно было бы ожидать. А в нашем отечественном дистрибутиве ASPLinux версии 7.3 (свидетельствую как очевидец — тестировал и даже написал).

В самом же Red Hat YUM, даже после выхода версии с мажорной единицей в имени (весна 2003 года), боролся за звание главного пакетного менеджера с apt-rpm. И ASPLinux был фактически единственным дистрибутивом, использующим новую систему. Пока, наконец, осенью того же года не возникла 1-я Fedora, с которой YUM и воссоединился — с тем, чтобы не расставаться по сей день.

А потом он прочно утвердился и в RHEL, и во всех его клонах, таких, как Scientific Linux, CentOS и Oracle Linux, а также в братском Yellow Dog. И теоретически может использоваться в любых rpm-based дистрибутивах — в частности, в Mandriva. не смотря на наличие штатной утилиты аналогичного назначения (urpmi), имеется соответствующий пакет — yum.

В настоящее время Сет Видал является сотрудником Red Hat, и вместе с группой товарищей, продолжает работу над YUM. Официальный сайт проекта, ранее живший на сервере Университете Дюка, ныне располагается здесь. На нём находятся исходники собственно пакета yum; и сопутствующих компонентов (yum-utils, yum-metadata-parser), как стабильных, так и разрабатываемых, и документация. Ну а плагины к YUM сочиняет большое количество самостоятельных разработчиков.

Post Scriptum. Сет Видал трагически погиб 8 июля 2013 года в ДТП. Светлая память.

Утилита yum

Как уже говорилось, главной и, фактически, самодостаточной частью системы YUM является утилита yum.

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

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

В общей форме командная директива yum выглядит так:

$ yum subcommand [arguments] --[options]

Команда yum без указания субкоманды выведет

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

Аналогичный результат будет получен посредством субкоманды yum help. А если здесь в качестве аргумента указать имя какой-либо субкоманды, то будут выведены краткие сведения о её назначении, например:

$ yum help install
...
Install a package or packages on your system

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

Yum: классификация субкоманд

Все субкоманды yum можно разделить, с одной стороны, по назначению, с другой по объектам применения.

По назначению выделяются, во-первых, субкоманды, связанные с поиском пакетов и получением информации о них, А во-вторых — предназначенные для манипулирования пакетами — установки, обновления, удаления.

По объектам применения выделяются субкоманды, предназначенные для работы с отдельными пакетами, и те, которые оперируют группами пакетов.

Yum: основные субкоманды

Основные субкоманды yum, предназначенные для получения информации о пакетах, таковы:

search [string] — поиск пакета по имени или его фрагменту;
list — вывод списка пакетов, всех (all или без указания фильтра), установленных (installed) или доступных (available);
repolist — вывод списка подключённых репозиториев;
resolvedep [shortname] — вывод полного имени пакета, с указанием номера версии, сборки и т.д., по его краткому имени;
provides filename — поиск пакета, содержащего указанный файл;
info pkgname — вывод полной информации о пакете;
deplist pkgname — вывод списка зависимостей указанного пакета;
check-update — вывод списка пакетов, для которых в данный момент доступны обновления.

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

В числе субкоманд, связанных с манипулированием пакетами, следующие:

install pkgname1 ... pkgname# — установка из репозиториев единичного пакета или нескольких пакетов, имена которых даны (в краткой форме) в качестве аргумента, вместе со всеми их зависимостями;
localinstall path2/fullname.rpm — установка пакета из локально хранящегося файла; зависимости его извлекаются из репозиториев, если таковые доступны;
update [pkgname] — обновление пакета, указанного в качестве аргумента; в отсутствие аргумента выполняется тотальное обновление системы;
upgrade — тотальное обновление системы для смены версии дистрибутива;
downgrade pkgname — “откат” пакета, заданного в качестве аргумента, на предыдущую версию из числа сохраняющихся в репозитории;
reinstall — переустановка ранее инсталлированного пакета, например, безнадёжно испорченного;
erase pkgname — удаление пакета вместе со всем, что от него зависит; пакеты, от которых зависит удаляемый, остаются в неприкосновенности, даже если они никем не используются; кроме того, может использоваться синоним этой субкоманды — remove;
makecache — запись метаданных репозиториев в локальный кэш;
clean — очистка локального кэша.

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

Субкоманд для работы с группами немного:

grouplist — вывод списка доступных групп пакетов;
groupinfo groupname — вывод информации о группе, имя которой указано в качестве аргумента;
groupinstall groupname — установка группы пакетов;
groupupdate groupname — обновление группы пакетов;
groupremove groupname — удаление группы пакетов.

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

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

Yum: начало работы

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

Синхронизация локального кэша с базами репозиториев занимает, в силу особенностей их формата, немалое время, и объем скачиваемой при этом метаинформации также изряден. Это тем более действует раздражающе, что в ряде случаев такая синхронизация во-первых, не нужна, и, во-вторых, при использовании yum от лица пользователя, бесполезна — реального обновления локального кэша при этом не происходит по понятной причине: у пользователя нет права записи в каталог /var/cache/yum, куда скачиваются соответствующие метаданные. Так что со временем мы изучим вопрос, как избавиться, при необходимости, от этой операции.

Однако до этого нам ещё далеко — пора начать знакомство с использованием наиболее употребимых субкоманд yum на практике.

“Информационные” субкоманды

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

Субкоманда repolist

Практическое использование yum мне показалось логичным начать с субкоманды repolist: ведь прежде всего надо знать, откуда берутся пакеты.

Данная в самой элементарной форме:

$ yum repolist

эта субкоманда выведет список подключённых репозиториев в следующем виде:

fedora	Fedora 14 - x86_64	22 161
rpmfusion-free	RPM Fusion for Fedora 14 - Free	411
...

Здесь в первой колонке мы видим те же идентификаторы репозиториев, во второй — полные их названия, с указанием релиза и архитектуры, в третьей — число пакетов.

Субкоманда repolist имеет три опции-фильтра: enabled, disabled и all. Первая выводит список подключённых репозиториев, точно так же, как и данная без всяких фильтров. Вторая выдаст список неактивизированных, но потенциально доступных репозиториев. И, наконец, третья, как явствует из её названия, показывает все репозитории с указанием их статуса:

Идентификатор репозитория	репозиторий		состояние
InstallMedia				Oracle Linux 6.	отключено
fedora						Fedora 14 - x86	включено:	22 161
fedora-chromium				Chromium web br включено:	12
fedora-chromium-source		Chromium web br отключено
...

Кроме обычного режима, субкоманда repolist имеет ещё и режим «подробный» (verbose), который вызывается добавлением опции -v. В этом случае для каждого репозитория списка выводятся подробные сведения примерно в таком виде:

Код репозитория      : fedora
Имя репозитория      : Fedora 14 - x86_64
Ревизия репозитория  : 1287930618
Метки репозитория    : binary-x86_64
Метки дистрибутива   : [cpe:/o:fedoraproject:fedora:14]: rawhide
Репозиторий обновлен : Sun Oct 24 18:49:34 2010
Пакеты репозитория   : 22 161
Размер репозитория   : 22 G
metalink репозитория : https://mirrors.fedoraproject.org/metalink?repo=fedora-14&arch=x86_64
  Обновлено          : Sun Oct 24 18:49:34 2010
Окончание срока репозитория: 604 800 секунд(а) (осталось: Thu Jun 30 19:23:31 : 2011

«Подробный» режим применим и при использовании опций-фильтров.

Субкоманда list

Теперь, ознакомившись с подключёнными репозиториями, не плохо выяснить, какие пакеты в них вообще имеются, какие из них уже установлены, а какие — доступны для установки. Для этого предназначена субкоманда list. В «чистом» виде — как

$ yum list

она «огласит весь список» пакетов, имеющихся в подключённых репозиториях.

Сначала пойдут установленные пакеты:

Installed Packages
Установленные пакеты
BlockOutII.x86_64	2.3-7.fc12	@fedora
ConsoleKit.x86_64	0.4.2-3.fc14	@updates
ConsoleKit-libs.x86_64	0.4.2-3.fc14	@updates
ConsoleKit-x11.x86_64	0.4.2-3.fc14	@updates
...

и так далее.

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

Далее следует список пакетов, доступных для установки — он выглядит точно так же. Завершается вывод списком команд, для которых доступны обновления (правда, в русском перевод сообщений yum он называется Обновленные пакеты).

Разобраться в этом изобилии пакетов (например, при моей конфигурации репозиториев их оказывается более 25 тысяч) сложно, да и не нужно. Потому что для этой субкоманды (как и для субкоманды repolist) существуют опции-фильтры. Первый из этих фильтров — all — равносилен отсутствию фильтра вообще, выводя всё тот же полный список пакетов.

Далее, посредством

$ yum list installed

можно просмотреть список только установленных пакетов (их у меня оказалось около полутора тысяч), с помощью

$ yum list available

— список только доступных, а команда

# yum list updates

— пакетов, для которых в данный момент существуют обновления.

Следующий фильтр —

# yum list obsoletes

выведет списко пакетов, наличествующих в системе, но удалённых из доступных репозиториев ввиду их устаревания. В их числе, скорее всего, могут оказаться сборки старых ядер.

А вот команда

# yum list extras

даст имена тех пакетов, которые наличествуют в системе, но недоступны в активизированных репозитория. В том числе и те, которые были установлены из сторонних и ныне не существующих репозиториев или просто «в лоб», посредством утилиты rpm.

Для всех перечисленных опций можно указать аргументы — имена пакетов или маски имён. Например

# yum list installed yum*

или

# yum list available yum*

для установленных или доступных пакетов, соответственно.

А вот команда

# yum list recent

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

Более продвинутые возможности фильтрации команде yum обеспечивает плагин yum-plugin-list-data, о котором речь пойдёт на одной из следующих страниц.

Субкоманда info

К сожалению, ни один из вариантов использования субкоманды list не выводит статуса каждого пакета, как, например, это делает aptitude для deb-пакетов. Однако эти сведения для единичного пакета (или нескольких пакетов) можно получить с помощью субкоманды info, которая заодно сообщит и много другой полезной информации.

Использование субкоманды info очень просто и требует только указания имени пакета в качестве аргумента, например:

Установленные пакеты
Name        : yum
Arch        : noarch
Version     : 3.2.28
Release     : 7.fc14
Size        : 4.1 M
Репозиторий : installed
From repo   : updates
Summary     : RPM installer/updater
Ссылка      : http://yum.baseurl.org/
License     : GPLv2+
Описание    : Yum is a utility that can check for and automatically download and
			: install updated RPM packages. Dependencies are   obtained and downloaded
            : automatically, prompting the user for permission as necessary.

Смыст всех строк понятен без комментариев. Обратим только внимание на строку Репозиторий, в которой и отмечен статус пакета. В данном примере значение installed показывает, что пакет уже установлен в системе, а строка From repo сообщает, из какого репозитория утсановка производилась.

Для пакета, отсутствующего в системе, первая из этих строк будет выглядеть так:

Репозиторий : updates

А строки From repo, естественно, не будет вовсе.

Аргументов у субкоманды info может быть сколько угодно — однако на практике резонно указывать столько пакетов, сколько можно окинуть одним или двумя взглядами на экран.

Субкоманда search

Субкоманда info для получения сведений о пакете требует знания его точного имени. Однако для малознакомого пакета это не всегда возможно — пользователь может помнить только фрагмент имени или некие слова, относящиеся к функциональности пакета. В этом случае на помощь ему придёт субкоманда search.

Формат этой субкоманды прост, требуя лишь аргумента в виде последовательности символов, каковая может представлять собой:

точное имя пакета;
фрагмент имени пакета;
некое слово (или набор слов), заведомо или предположительно имеющие отношение к функциональности пакета.

Субкоманда search выполняет поиск символьных последовательностей, совпадающих с определённой в качестве аргумента, в именах пакетов репозиториев, в кратком (Summary) и полном (Description) их описаниях, и по результатами поиска выводит или

точное имя пакета, сопровождаемое кратким описанием, повторяющим содержимое поля Summary, например:

$ yum search yumex
Matched: yumex
yumex.noarch : Yum Extender graphical package management tool

или список пакетов, удовлетворяющих заданному критерию:

$ yum search "video driver"
Matched: video driver
xorg-x11-drv-apm.x86_64 : Xorg X11 apm video driver
xorg-x11-drv-ark.x86_64 : Xorg X11 ark video driver
xorg-x11-drv-ast.x86_64 : Xorg X11 ast video driver
xorg-x11-drv-ati.x86_64 : Xorg X11 ati video driver
...

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

В случае, если вывод субкоманды search оказывается очень длинным и содержит не интересующие нас пакеты, его можно передать по конвейеру команде grep. Например, таким образом

$ yum search yum | grep yum-plugin

можно выловить все плагины для yum:

yum-plugin-downloadonly.noarch : Yum plugin to add downloadonly command option
yum-plugin-fs-snapshot.noarch : Yum plugin to automatically snapshot your
yum-plugin-merge-conf.noarch : Yum plugin to merge configuration changes when
...

К сожалению, и в выводе субкоманды search статус найденных пакетов не отображается — для его определения надо вернуться к субкоманде info.

Субкоманда provides

Иногда перед пользователем встаёт задача поиска пакета не по его имени или описанию, а по конкретному файлу, в нём содержащемуся.

Как говорилось в разделе об утилите rpm, при нарушении зависимостей она их не разрешает, а только сообщает об ошибке. Причём подчас в виде указания не на недостающий пакет, а на отсутствие конкретного файла, обычно библиотечного, вида libname.so. И вот тут-то и пригодится субкоманда provides, выполняющая поиск пакета по содержащемуся в нём файлу.

Реальный пример я привести затрудняюсь, поскольку в чистом виде утилитой rpm пользуюсь очень редко и только в очень простых случаях. Так что чисто условно предположим, что нам требуется определить, в какой пакет входит библиотека, скажем, katepart.so. Для этого даём команду

$ yum provides katepart.so

И получаем вывод такого вида:

6:kdelibs-4.5.2-5.fc14.i686 : KDE Libraries
Repo        : fedora
Matched from:
Other       : katepart.so

6:kdelibs-4.6.3-5.fc14.i686 : KDE Libraries
Repo        : updates
Matched from:
Other       : katepart.so

Если же мы выполним поиск по файлу, входящему в установленный пакет, то в вывод субкоманды provides добавится ещё одна секция примерно такого вида:

Repo        : installed
Matched from:
Other       : Provides-match: libname.so

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

Субкоманда deplist

Тем или иным способом отыскав интересующий нас пакет и убедившись, что в системе он отсутствует, можно приступать к его установке. Но перед этим не вредно проделать процедуру определения его зависимостей — не обязательную, но полезную. Этой цели служит субкоманда deplist.

Её использование также очень просто — надо лишь указать имя пакета, для которогоищутся зависимости, например:

$ yum deplist zsh

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

Finding dependencies:
package: zsh.x86_64 4.3.10-6.fc14
  dependency: libc.so.6(GLIBC_2.11)(64bit)
   provider: glibc.x86_64 2.12.90-17
   provider: glibc.x86_64 2.13-1
  dependency: libgcc_s.so.1()(64bit)
   provider: libgcc.x86_64 4.5.1-4.fc14
  dependency: /bin/sh
   provider: bash.x86_64 4.1.7-3.fc14
...

Помимо удовлетворения здорового людобытства, субкоманда deplist может иногда иметь и практическое значение, например, при установке — для выявления конфликтов зависимостей с уже установленными пакетами, или при удалении пакетов, оставляющих после себя «сиротские» зависимости (то есть пакеты, от которых уже ничего не зависит). Хотя с первой задачей yum справляется всегда, насколько я знаю, автоматически. А на страницах, посвящённых плагинам, мы увидим, как избежать «сиротских» зависимостей в принципе.

Ускорение работы “информационных” субкоманд

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

В силу специфики формата RPM, процесс этот весьма задумчив. Так что, когда требуется быстро найти определённый пакет или получить о нём информацию, он не вызывает ничего, кроме раздражения. Тем более, что, как правило, в таких случаях синхронизация и не нужна (всё обычно синхронизировано), и бесполезна («информационные» субкоманды лучше давать от лица пользователя, а у него нет права записи в соответствующий каталог). Так что рамках нашей текущей темы от неё лучше бы избавиться.

Благо, сделать это можно весьма просто: на сей предмет существует опция -C (она же --cacheonly). Например:

$ yum -C search pkgname

или

$ yum -C info pkgname

Теперь, как явствует из имени полной формы этой опции, метаданные будут считываться из локального кэша системы (/var/cache/yum/[arch]/[release]), а не скачиваться по сети.

А в разделе про интеграцию yum и zsh я расскажу, как сделать это не просто, а очень просто.

“Манипуляционные” субкоманды

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

Памятка будущему root’у

Как уже говорилось, все «манипуляционные» действия требуют полномочий администратора. Так что для начала напомню способы получения прав root’а (для простоты — на примере субкоманды install).

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

Однако способ этот хотя и самый простой — но и, мягко говоря, не лучший. По поводу недостатков постоянного нахождения под root’овым аккаунтом сказано достаточно, и повторяться не буду. Но, кроме всего прочего, это ещё и банально неудобно: нынче большая часть пользователей постоянно пребывает в графическом режиме, и переключаться в консоль для выполнения разовой операции, например, по установке пакета не сподручно.

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

В дистрибутиве Fedora, в отличие от Ubuntu, например, для временного доступа к правам суперпользователя традиционно используется команда su. В простейшей своей форме —

$ su

она открывает внутри пользовательского сеанса вторичный сеанс root‘а, с заменой переменных окружения, но с сохранением текущего, до отдачи команды, каталога. Если же дать её в форме

$ su -

то этого никаких отличий от ситуации, когда мы авторизовались root’ом в ответ на первичное приглашение в консоли, не обнаружится. В том числе и текущий каталог, в котором была отдана команда, сменится на домашний каталог суперпользователя — /root.

После получения прав администратора любым из этих двух способов становятся доступными все субкоманды yum, связанные с манипулированием файлами. Надо только по завершении этого дела не забыть выйти из root’ового сеанса командой quit или exit.

Команду su можно использовать и для разовой операуии по установке, обновлению или удалению пакета (пакетов). В этом случае она примет такую форму:

$ su -c 'yum install pkg_name1 ... pkg_name#'

где опция -c или --command=команда как раз и определяет исполнение единичной команды. После этого последует запрос пароля суперпользователя и установка пакета (пакетов). По завершении процесса автоматически, без всяких дополнительных команд, восстанавливается сеанс обычного пользователя.

Обращаю внимание на строгие кавычки, в которые следует заключить всю командную конструкцию после команды su. Причём сразу после открытия строгой кавычки в командной строке перестаёт работать автодополнение, вне зависимости от шелла и его настроек. Это делает предпочтительным при установке единичного пакета использование команды sudo.

Начиная с релиза 14, в Fedora (по крайней мере в RFRemix) можно разрешить использование sudo для определённого пользователя сразу после установки, на стадии Firstboot. Если это почему-либо не было сделано, настроить его для элементарного использования — так же элементарно.

Использовать sudo для манипуляций с пакетами ещё более просто, например, так:

$ sudo yum install pkg_name

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

В течении некоторого времени (по умолчанию — трёх минут) процедуру установки можно повторить уже без ввода пароля. Если же предполагается работать под административным аккаунтом более продолжительное время — имеет смысл получить его права «бессрочно». Оптимальный способ для этого — такая команда:

$ sudo -i

Результат её эквивалентен действию команды su -: пользователь оказывается в полноценном сеансе root’а, со всеми его переменными окружения. И, естественно, по завершении административных действий из этого сеанса надо будет выйти — всё теми же командами quit или exit.

Более подробно с использованием команд ud и ud можно ознакомиться здесь.

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

“Групповые” субкоманды

Разобравшись с методами работы yum с отдельными пакетами, посмотрим, как же он обращается с их группами.

О группах пакетов

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

Группа пакетов (иногда называемые также коллекциями) — это некий их набор, объединённый по назначению и имеющий собственное имя, например, Administration Tools, Web Server или GNOME Desktop Environment. В сущности, это то же самое, что метапакеты (или метапорты) FreeBSD или Tasks в deb-based дистрибутивах. Каждая такая целевая группа устанавливается одной командой и, при необходимости, одной же командой может быть удалена, вместе со всеми входящими в неё пакетами.

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

Однако связи между пакетами в группе и зависимостями различны. Зависимости прописаны внутри rpm-пакета, и принудительное их нарушение (а, как мы видели в разделе о rpm, это возможно) почти всегда приводит к неработоспособности пакетов, зависимых от принудительно удалённого.

Состав же группы описывается во внешнем, так называемом comps-файле. Он лежит в каждом из основных репозиториев в каталоге .../arch/os/repodata и представляет собой простой xml-файл, сжатый утилитой gzip (вида *.comps.xml.gz).

Содержимое comps-файла — перечень названий групп пакетов, сопровождаемых кратким описанием (и то, и другое — на языках всех доступных локалей) и списком входящих в группу пакетов. Наглядно, в виде нормальной html-страницы, и перечень групп, и список входящих в них пакетов можно увидеть с помощью браузера, если перейти в каталог .../arch/os/repoview примерно в таком виде:

yum02 — Список пакетов группы Administration Tools

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