Crazy Rebel: викификация, оформление, иллюстрация

2010-12-03T14:37:31Z

викификация, оформление, иллюстрация

Новая статья

==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'' – кит пакетного менеджмента===

{{Врезка| Содержание= [[Изображение:LXF125_42_1.jpg|300px]] ''PackageKit'' — общий вид. Пароль root запрашивается по ходу процесса.| Ширина= 300px}}

Если ''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».

{{Врезка| Содержание= [[Изображение:LXF125_43_1.jpg|300px]] Журнал установки, обновления и удаления пакетов.| Ширина= 300px}}

Все действия по установке и удалению пакетов через ''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'' нам в руки.

LXF125:Yum - История изменений

Crazy Rebel: /* Тонкий тюнинг */

Crazy Rebel: /* Часть 1: Незнаменитый ''Yum'' */

Crazy Rebel: викификация, оформление, иллюстрация

← Предыдущая		Версия 14:38, 3 декабря 2010
Строка 92:		Строка 92:
	название=значение		название=значение

-	Значение может быть булевым (0 – запрещено, 1 – разрешено), численным – от 1 и до... разумного предела (0 равносильно	+	Значение может быть булевым (0 – запрещено, 1 – разрешено), численным – от 1 и до... разумного предела (0 равносильно
	отключению), или символьным – например, путем к каталогу или списком пакетов; в последнем случае значения разделяются пробелами. По умолчанию установлено следующее:		отключению), или символьным – например, путем к каталогу или списком пакетов; в последнем случае значения разделяются пробелами. По умолчанию установлено следующее:
	* '''cachedir=/var/cache/yum''' Каталог для кэширования метаданных репозиториев и пакетов, скачиваемых в ходе установки.		* '''cachedir=/var/cache/yum''' Каталог для кэширования метаданных репозиториев и пакетов, скачиваемых в ходе установки.

← Предыдущая		Версия 14:37, 3 декабря 2010
Строка 17:		Строка 17:
	''Yum'' быстро получил признание среди ряда клонов Red Hat – в частности, был принят в качестве штатного менеджера пакетов в ASPLinux. Однако в самом Red Hat он долго конкурировал с ''apt-rpm'', и развитие ''Yum''’а одно время только силами команды ASPLinux и осуществлялось. Однако в конце концов он утвердился в RHEL и его клонах (CentOS, Scientific Linux), в Fedora и в Yellow Dog.		''Yum'' быстро получил признание среди ряда клонов Red Hat – в частности, был принят в качестве штатного менеджера пакетов в ASPLinux. Однако в самом Red Hat он долго конкурировал с ''apt-rpm'', и развитие ''Yum''’а одно время только силами команды ASPLinux и осуществлялось. Однако в конце концов он утвердился в RHEL и его клонах (CentOS, Scientific Linux), в Fedora и в Yellow Dog.

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