Fedora: управление пакетами. Rpm: формат и утилита

FOSS-системы вообще, и Fedora в частности, организованы по пакетному принципу. Точно также, в виде пакетов, распространяются и любые дополнительные программы для них, создаваемые независимыми разработчиками. И потому одна из важных задач пользователя – это интеграция пакетов в свою систему. Пакеты для Fedora распространяются в формате rpm.

Формат rpm

Изобретение формата пакетов rpm и соответствующей утилиты для управления ими оказало очень большое влияние на Linux-дистрибуцию вообще. Так что надо уделить ему толику внимания.

История

Формат пакетов RPM (что тогда расшифровывалось как Red Hat Package Manager) и одноимённая утилита для манипулирования такими пакетами, способная отслеживать зависимости и сообщать об их нарушении, сыграли очень большую роль в приобщении к Linux’у широких народных масс. Правда, разрешать зависимости эта утилита не умела, да и не научилась по сей день: задача эта решается более «продвинутыми» средствами пакетного менеджмента. Но по сравнению с молчаливым пакетным инструментарием из Slackware, зависимости вообще не отслеживающим, и это было большим прогрессом с точки зрения обычных пользователей.

Происхождение системы RPM (будем понимать под этим и набор утилит, и формат пакетов, с которыми они работают) теряется во мраке веков. В первых версиях Red Hat использовалась система RPP, обеспечивающая установку пакетов одной командой, запрос информации о них, а также проверку зависимостей. Однако сборка пакетов для неё требовала существенной модификации авторских исходников, что было напряжно для майнтайнеров дистрибутива.

Параллельно раннему Red Hat некоторое время развивался дистрибутив Bogus, ныне мало кому известный. В нём имелась собственная пакетная система — PMS (Package Management System), написанная Рикардом Файтом (Rikard E. Faith). Она обладала слабым механизмом запросов информации о пакетах, а проверка их зависимостей просто отсутствовала. Но зато пакеты для PMS можно было собирать непосредственно из авторских исходников, без всякой их модификации.

В ходе подготовки 2-го релиза Red Hat Рикард Файт вместе с Дугом Хоффманом (Doug Hoffman) по контракту с компанией Red Hat написали систему PM (Package Management), вобравшую в себя лучшие особенности RPP и PMS. Хотя практически она так и не была задействована, но послужила одной из основ для RPM.

Собственно система RPM была создана Марком Юингом (одним из сооснователей компании) и Эриком Троэном (Erik Troan), основывавшихся на всех достижениях предшественников — разработчиков RPP, PMS и PM. Вариант её, подготовленный для тестовых версий второго релиза, быстроты ради был написан на Perl’е, что создавало ряд проблем, например, при загрузке с дискеты (а в те времена это было достаточно обычным способом старта Linux’а). И непосредственно к выходу релиза Red Hat 2.0 система была полностью переписана на C, база данных пакетов перепроектирована для пущей надёжности и быстродействия, а для использования функциональности RPM сторонними разработчиками была создана библиотека rpmlib. Иными словами, система RPM приобрела практически тот вид, в каком мы знаем её ныне, подвергаясь с тех пор только корректировке ошибок и косметическим доделкам.

Система RPM (то есть формат и утилита), став штатными и общедоступными в релизе Red Hat 2.0, вышедшем в сентябре 1995 года, сразу завоевали популярность и вне родительской системы. Вскоре они были использованы в Caldera Linux (позднее именовавшаяся OpenLinux), которая поначалу была точным клоном Red Hat. Вслед за тем на пакетирование в формате rpm перешёл дистрибутив Suse (генетически — потомок Slackware). Разумеется, и все последующие клоны и дериваты Red Hat, например, Mandrake, также использовали RPM.

Могу свидетельствовать как очевидец, что к рубежу 1996–1997 годов (времени моих первых экспериментов с Linux) система RPM была широко распространённой, считалась стабильно работающей и использовалась далеко за пределами родного дистрибутива.

Общие сведения

За свою долгую жизнь формат rpm претерпевал различные изменения, однако в генеральной своей линии сохранял как свои характерные черты, так и обратную совместимость вплоть до настоящего времени. Текущая его версия из числа официально поддерживаемых одноимённым проектом на настоящий момент (01.02.2011) — 4.8.1. Она используется в бессчётном числе дистрибутивов, представляющих как прямые клоны Red Hat (CentOS, Scientific Linux, Oracle Enterprise Linux), так и его дериваты пусть даже удалившиеся от прародителя, вроде Mandriva или Altlinux. Кроме того, его можно видеть даже в некоторых системах, генетически с ним не связанных (например, во всех вариантах Suse).

Параллельно генеральной версии rpm развивается и её обновлённый вариант, известный как rpm5. Он создан Джеффом Джонсоном (Jeff Johnson), бывшим до того одним из основных разработчиков “обычного” rpm. Согласно его мнению, новая версия существенно усовершенствована по сравнению со своим предком, за что, однако пришлось заплатить отсутствием совместимости между этими двумя форматами. Поэтому rpm5 официально не поддерживается ни проектом rpm, ни одним из распространённых rpm based дистрибутивов. Он используется, насколько я знаю, только в дистрибутиве PLD и, согласно анонсу, будет задействован в релизе Mandriva 2011.1

Не смотря на то, что в перечисленных rpm-based дистрибутивах (и многих других, не перечисленных) теоретически используется один и тот же формат пакетов, на самом деле детали их устройства отличаются. Особенно это касается пакетов исходников (о которых будет отдельный разговор). Однако на этих страницах я ограничусь рассмотрением rpm-пакетов для дистрибутива Fedora. Правда, сказанное о них будет иметь силу и для RHEL, CentOS, Scientific Linux, Oracle Enterprise Linux, ASPLinux.

Номенклатура пакетов

В составе дистрибутива Fedora можно обнаружить разные виды пакетов интересующего нас формата.

Во-первых, выделяются rpm-пакеты бинарные и они же, но с исходными текстами. Как явствует из названия, первые содержат прекомпилированные компоненты дистрибутивного пакета, как то:

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

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

Распознать те и другие очень легко по их именам, образованным по определённым правилам, каковые мы рассмотрим на примере самого показательного пакета — собственно пакета rpm

Имена бинарных rpm-пакетов образованы по следующей схеме:

rpm-4.8.1-6.fc14.x86_64.rpm

где rpm — имя пакета, 4.8.1 — номер ветки, версии и конкретного релиза пакета, 6 — номер сборки для текущей версии данного дистрибутива, fc14 — имя и версия такового (то есть, в данном примере, — Fedora версии 14), x86_64 — архитектура, под которую пакет собирался.

Имя пакета с исходниками будет похожим:

rpm-4.7.1-6.fc12.src.rpm

Можно видеть, что отличие только в добавочном суффиксе src, символизирующего, что мы имеем дело именно с пакетом исходников, а не с прекомпилированным бинарником. И очевидно, что понятие архитектуры для исходных текстов смысла не имеет — они (теоретически) должны собираться для любой из них.

Среди бинарных пакетов также можно найти такие, которые не привязаны к какой-либо архитектуре — они опознаются по дополнительному суффиксу noarch. В их числе — сценарии на интерпретируемых языках типа Perl, Python etc, шрифтовые пакеты, документация и так далее. Например, так будет выглядеть пакет для одной из гарнитур шрифтового семейства Dejavu:

dejavu-sans-fonts-2.30-2.fc12.noarch.rpm

Выше уже говорилось, что бинарные rpm-пакеты могут содержать библиотеки функций, необходимых для их функционирования. Однако это — скорее исключение: как и во всех UNIX-подобных системах, в rpm-based дистрибутивах существует тенденция собирать библиотеки как отдельные пакеты. При этом каждая библиотека, как правило, представлена в виде двух пакетов.

Первый пакет содержит собственно код библиотечных функций, необходимых в любом случае; например, работу пакета rpm обеспечивает библиотечный пакет

rpm-libs-4.7.1-6.fc12.x86_64.rpm

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

rpm-devel-4.7.1-6.fc12.x86_64.rpm

Разобравшись с номенклатурой rpm-пакетов, можно перейти к вопросу их внутреннего устройства — то есть к собственно формату.

Устройство бинарных rpm-пакетов

Бинарный пакет rpm включает в себя два компонента. С одной стороны, это набор скомпилированных файлов, таких, как исполняемые бинарники и библиотеки, сопровождаемых необходимыми конфигами, документацией и т.д., готовый к инкорпорацию в файловую иерархию системы.

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

Компоненты rpm-пакета запаковывается в архив cpio — одно из древнейших средств архивирования в UNIX, подвергнутый компрессии. Ранее, вплоть до Fedora версии 11 включительно, это делалось посредством утилиты gzip. Начиная с 12-й версии Fedora rpm-пакты сжимаются по алгоритму LZMA, обеспечивающему много большую степень компрессии — правда, ценой времени, на неё затрачиваемого. Что для пользователя, впрочем, неудобств не доставит — потому что распаковка lzma-файлов, как это ни парадоксально, осуществляется практически с той же скоростью, что и gzip. А вот скачивание их, разумеется, происходит много быстрее, что не может не радовать обладателей “толстых” и дешёвых каналов: при этих условиях установка пакетов по Сети происходит быстрее, нежели с локальных носителей.

Вернёмся, однако, к тому, что у rpm-пакета “внутре”. Для чего сначала распакуем пакет любым стандартным средством (rpm2cpio, например, или с помощью утилиты rpm2tgz) и посмотрим, что получилось:

$ ls rpm-4.7.1-6/
bin/  etc/  usr/  var/

То есть мы видим те компоненты пакета, которые будут инкорпорированы в файловую иерархию целевой системы.

Знакомство со вторым компонентом проще всего сделать с помощью Midnight Commander. По клавише F3 (по прежнему для примера рассматривается пакет rpm) он выдаст всю метаинформацию в суммарном виде. Сначала это будет формальное описание пакета:

Name        : rpm                          Relocations: (not relocatable)
Version     : 4.8.1                             Vendor: Fedora Project
Release     : 5.fc14                        Build Date: Втр 10 Авг 2010 11:43:21
Install Date: (not installed)               Build Host: x86-12.phx2.fedoraproject.org
Group       : System Environment/Base       Source RPM: rpm-4.8.1-5.fc14.src.rpm
Size        : 2035701                          License: GPLv2+
Signature   : RSA/SHA256, Срд 11 Авг 2010 05:58:10, Key ID 421caddb97a1071f
Packager    : Fedora Project
URL         : http://www.rpm.org/
Summary     : The RPM package management system
Description :
The RPM Package Manager (RPM) is a powerful command line driven
package management system capable of installing, uninstalling,
verifying, querying, and updating software packages. Each software
package consists of an archive of files along with information about
the package like its version, a description, etc.

Смысл всех полей интуитивно понятен. Прошу только обратить внимание на поле Group: о групповой принадлежности пакета нам придётся вспомнить, когда дело дойдёт до управления пакетами с помощью системы yum.

Затем последует установочный сценарий:

posttrans scriptlet (using /bin/sh):
# XXX this is klunky and ugly, rpm itself should handle this
dbstat=/usr/lib/rpm/rpmdb_stat
if [ -x "$dbstat" ]; then
    if "$dbstat" -e -h /var/lib/rpm 2>&1 | grep -q "doesn't match environment version | Invalid
 argument"; then
        rm -f /var/lib/rpm/__db.*
    fi
fi
exit 0

Далее можно видеть список входящих в пакет файлов с полными путями, определяющими их положение в файловой иерархии. Сначала идут исполняемые бинарники:

-rwxr-xr-x    1 root    root                    20392 Авг 10 11:42 /bin/rpm
drwxr-xr-x    2 root    root	0 Авг 10 11:42 /etc/rpm
-rwxr-xr-x    1 root    root	7424 Авг 10 11:42 /usr/bin/rpm2cpio
...

Затем — библиотечные файлы:

-rw-r--r--    1 root    root	40537 Авг 10 11:42 /usr/lib/rpm/macros
drwxr-xr-x    2 root    root	0 Авг 10 11:42 /usr/lib/rpm/platform
drwxr-xr-x    2 root    root	0 Авг 10 11:42 /usr/lib/rpm/platform/amd64-linux
...

Далее — файлы разделяемые:

-rw-r--r--    1 root    root	44206 Дек  7  2009 /usr/share/doc/rpm-4.8.1/COPYING
-rw-r--r--    1 root    root	639 Дек  7  2009 /usr/share/doc/rpm-4.8.1/CREDITS
-rw-r--r--    1 root    root	496233 Июн 11  2010 /usr/share/doc/rpm-4.8.1/ChangeLog.bz2
-rw-r--r--    1 root    root	656 Дек  7  2009 /usr/share/doc/rpm-4.8.1/GROUPS
...

И, наконец, файлы вариативные:

drwxr-xr-x    2 root    root	0 Авг 10 11:42 /var/lib/rpm
-rw-r--r--    1 root    root	0 Авг 10 11:42 /var/lib/rpm/Basenames
-rw-r--r--    1 root    root	0 Авг 10 11:42 /var/lib/rpm/Conflictname
-rw-r--r--    1 root    root	0 Авг 10 11:42 /var/lib/rpm/Dirnames
...

Всю эту информацию можно просмотреть и по частям — зафиксировав в Midnight Commander курсор на файле

rpm-4.7.1-6.fc12.x86_64.rpm

и нажав Enter.
Теперь мы увидим список входящих в пакет “метаинформационных” файлов:

/..              │-ВВЕРХ-│Дек 16 12:04
/INFO            │      0│Сен 21 00:00│
CONTENTS.cpio   │      0│Сен 21 00:00
HEADER          │   1185│Сен 21 00:00
*INSTALL         │     39│Сен 21 00:00
*UPGRADE         │     39│Сен 21 00:00

О содержимом файлов легко догадаться. Так, CONTENTS.cpio — полный список всех файлов и путей к ним:

-rwxr-xr-x   1 root     root        20808 Sep 21 17:30 ./bin/rpm
drwxr-xr-x   2 root     root            0 Sep 21 17:30 ./etc/rpm
...

и так далее. Файл HEADER содержит то самое описание, которое мы только что видели через F3, *INSTALL и *UPGRADE — исполняемые скрипты соответствующего назначения. А в каталоге /INFO лежит множество мелких файликов, из которых в итоге собирается суммарная метаинформация. Из них остановлюсь только на REQUIRENAME — это пресловутый перечень зависимостей, который для пакета rpm выглядит примерно так:

/bin/bash
/bin/sh
/bin/sh
config(rpm) = 4.8.1-5.fc14
coreutils
curl
db4-utils
libacl.so.1()(64bit)
...

И так далее, единым списком, без разделения на зависимости “жесткие” и “мягкие”.

На самом деле пакет rpm никакой файловой иерархии внутри себя не содержит. А то, что нам представляется в виде таковой — всецело заслуга Midnight Commander, который восстанавливает её в том виде, в котором она была до сборки.

База данных RPM

База данных rpm-пакетов — компонент, необходимый для функционирования системы: именно она обеспечивает возможность получения информации о пакетах, их обновления и удаления. Она создаётся при инсталляции системы в каталоге /var/lib/rpm и изменяется при каждой операции с пакетами.

База данных rpm-пакетов использует Berkeley DB — древнюю (1986 года розлива), простую (нереляционную) СУБД, однако быструю, эффективную и потому широко используемую по сей день.

Файлы базы RPM — бинарные, и даже волшебство «ночного командира» не позволит разглядеть в них что-либо удобопонятное. Так что остаётся только поверить на слово авторам документации, что

  • файл Packages является главным и хранит индексированные поля заголовков пакетов,
  • файлы Basenames, Group, Requireversion и прочие служат для оптимизации запросов к базе, а
  • файлы __db.001, __db.002 и так далее — содержат в себе сведения о том, какие файлы менялись и создавались при установке и удалении пакетов.

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

Утилита rpm

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

Введение

Как уже было сказано, утилита rpm стала благословением пользователей дистрибутива Red Hat и всех его наследников. Ибо она освобождала их от необходимости самостоятельной компиляции: практически все разработчики из числа не брезговавших распространением своих пакетов в бинарном виде, собирали их в rpm-формате, а службы вроде http://rpmfind.net позволяли легко отыскать их на просторах Сети. Помню, в те годы имела хождение такая жизненная максима:

с помощью rpm и Инета любые дистрибутивы можно сделать близнецами-братьями за одну ночь

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

Те времена канули в Лету: наступил век пакетных репозиториев и средств для работы с ними, таких, как apt-rpm, urpmi и, наконец, yum — главный герой следующего цикла заметок. Каковые и берут на себя заботу по рутинному манипулированию пакетами. Однако утилита rpm до сих пор остаётся самым простым средством для операций с единичными пакетами, особенно не входящими в официальные репозитории. А в некоторых случаях — например, при подключении репозиториев сторонних — она может оказаться практически незаменимой.

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

Общая характеристика

Утилита rpm, подобно dpkg в Deb-based дистрибутивах, — лишь одна из представительниц целого семейства, разрабатываемого, вместе с одноимённым форматом, в рамках самостоятельного проекта.

Из числа дополнительных утилит стоит упомянуть rpm-build — средство для создания собственных пакетов, и rpm2html — утилиту для извлечения метаинформации из пакетов и представления её в человеческом виде (полный список всего семейства можно найти здесь). Однако в начале настоящего цикла страниц речь пойдёт только о собственно rpm.

Существует пять основных режимов использования утилиты rpm:

  • режим запроса (query);
  • режим проверки (verify);
  • режим установки (install);
  • режим обновления (upgrage);
  • режим удаления (erase).

Существует также режим построения пакета, но о нём мы пока говорить не будем.

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

  • -?, --help вывод подробной справки об использовании команды rpm (краткая справка выводится в ответ на команду без всяких опций и аргументов);
  • --version вывод номера версии пакета rpm;
  • --quiet вывод минимума сообщений в ходе выполнения команды (обычно это только сообщения об ошибках);
  • -v вывод подробных сообщений о ходе выполнения команды.

Есть также несколько «внережимных» опций, используемых, в частности, для восстановления базы данных пакетов.

Аргументом команды rpm обычно является имя файла пакета; часто таких аргументов может быть несколько (в пределе — сколько угодно). В одних случаях достаточно указания краткого имени пакета — например, для нашего постоянного примера просто rpm. В других же ситуациях требуется указание полного имени, с указанием номера версии, сборки, дистрибутива, архитектуры — например, rpm-4.8.1-5.fc14.x86_64.rpm. А если файл пакета находится не в текущем каталоге, то потребуется предварить его указанием полного пути к нему, скажем /var/cache/akmods/.

Режим запроса…

… служит для получения информации о пакете, в частности, его статусе (установлен ли он в системе). Основная опция запроса — -q (или --query), в ответ на неё последует вывод полного имени пакета:

rpm -q rpm
rpm-4.8.1-5.fc14.x86_64

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

Дополнительные опции зависят от цели запроса. Так, наличие пакета в системе проверяется следующей командой:

$ rpm -qa pkgname

где дополнительная опция -a (или --all) предписывает запрос ко всем наличным в базе пакетам. Если пакет установлен, ответом на эту команду будет

$ rpm -qa opera
opera-10.00-4440.gcc4.shared.qt3.x86_64

Если нет — последует возврат приглашения командной строки.

Формальное описание пакета можно получить командой

$ rpm -qi rpm

ответом на что будет:

Name        : rpm                          Relocations: (not relocatable)
Version     : 4.8.1                             Vendor: Fedora Project
Release     : 5.fc14                        Build Date: Втр 10 Авг 2010 11:43:21
Install Date: Вск 31 Окт 2010 10:28:06      Build Host: x86-12.phx2.fedoraproject.org
Group       : System Environment/Base       Source RPM: rpm-4.8.1-5.fc14.src.rpm
Size        : 2035701                          License: GPLv2+
Signature   : RSA/SHA256, Срд 11 Авг 2010 05:58:10, Key ID 421caddb97a1071f
Packager    : Fedora Project
URL         : http://www.rpm.org/
Summary     : The RPM package management system
Description :
The RPM Package Manager (RPM) is a powerful command line driven
package management system capable of installing, uninstalling,
verifying, querying, and updating software packages. Each software
package consists of an archive of files along with information about
the package like its version, a description, etc.

Легко видеть, что это та самая заголовочная часть (HEADER), которую мы ранее просматривали через Midnight Commander.

Дополнительная опция l позволит вытащить нам и содержимое CONTENTS.cpio:

$ rpm -ql rpm
/bin/rpm
/etc/rpm
/usr/bin/rpm2cpio
/usr/bin/rpmdb
/usr/bin/rpmquery
/usr/bin/rpmsign
/usr/bin/rpmverify
...

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

Выше речь касалась получения информации об установленном пакете. Однако гораздо интересней получить сведения о пакете не установленном — на предмет нужности или не нужности его в нашем деле. И это возможно — путем добавления к -qi дополнительной опции p и указания полного имени пакета и пути к нему. А поскольку не установленный пакет, скорее всего, лежит на каком-либо сетевом источнике, то в качестве пути тут будет фигурировать URL, например:

$ rpm -qip http://mirror.yandex.ru/fedora/linux/releases/14/Fedora/x86_64/os/Packages/joe-3.7-5.fc13.x86_64.rpm

Что выведет точно такую же информацию, что и при запросе к локальному пакету:

Name        : joe                          Relocations: (not relocatable)
Version     : 3.7                               Vendor: Fedora Project
Release     : 5.fc13                        Build Date: Срд 10 Фев 2010 09:57:06
Install Date: (not installed)               Build Host: x86-03.phx2.fedoraproject.org
Group       : Applications/Editors          Source RPM: joe-3.7-5.fc13.src.rpm
Size        : 1177186                          License: GPLv2+
Signature   : RSA/SHA256, Срд 28 Июл 2010 21:59:42, Key ID 421caddb97a1071f
Packager    : Fedora Project
URL         : http://sourceforge.net/projects/joe-editor/
Summary     : An easy to use, modeless text editor
Description :
Joe is a powerful, easy to use, modeless text editor.
It uses the same WordStar keybindings used in Borland's development
environment.

Дополнительная опция f позволяет определить имя пакета, которому принадлежит некий файл:

$ rpm -qf /usr/lib/rpm/rpm2cpio.sh
rpm-4.8.1-5.fc14.x86_64

В режиме запроса возможны и ещё многие опции, с которыми при необходимости можно ознакомиться на man-странице пакета rpm.

Режим проверки…

… обеспечивает проверку целостности установленного пакета. Делается это путём сравнения его файлов с их аналогами из пакета оригинального по таким параметрам, как тип, размер, контрольная сумма (MD5), атрибуты принадлежности и доступа. Основная опция этого режима — -V; без дополнительных опций, с указанием имени пакета, она проверяет правильность расположения его файлов в файловой иерархии.

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

  • 5 — контрольная сумма MD5
  • S — размер
  • L — символическая ссылка
  • T — дата изменения файла
  • D — устройство
  • U — пользователь
  • G — группа
  • M — режим (включая разрешения и тип файла)
  • ? — файл не удалось прочитать

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

И к тому же, не всегда вывод какого-либо сообщения означает, что с установленным пакетом что-то не в порядке. Например, если попробовать верифицировать наш моедльный пакет rpm командой

$ rpm -V rpm

мы на выводе увидим следующее:

prelink: /bin/rpm: at least one of file's dependencies has changed since prelinking
S.?......    /bin/rpm
prelink: /usr/bin/rpm2cpio: at least one of file's dependencies has changed since prelinking
S.?......    /usr/bin/rpm2cpio

Это означает всего-навсего, что исполняемый файлы пакета rpm после его установки подверглись процедуре предварительного связывния (prelink — что это такое, я расскажу со временем). В результате чего, разумеется, утратили идентичность со своими тёзками из оригинального пакета.

Дополнительные опции режима проверки позволяют выполнить верификацию конкретного файла:

$ rpm -Vf /usr/bin/rpm2cpio

сравнить установленный пакет с его исходным rpm-пакетом:

$ rpm -Vp path2/full_packagename

а также выполнить полную проверку всех установленных пакетов:

# rpm -Va

Поскольку вывод последней команды будет очень длинным, её целесообразно использовать в корнвейере с командой типа less или most. Можно также с помощью команды grep выявить только пакеты; содержащие расхождения с оригиналом по одному из перечисленных выше критериев. Например, командная конструкция

# rpm -Va | grep S

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

# rpm -Va | grep 5

выявит различия контрольных сумм.

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

Кроме перечисленных, существуют ещё многочисленные опции верификации цифровой подписи и публичных ключей — с ними, как обычно, можно ознакомиться на странице man (8) rpm.

Режимы установки и обновления…

… тесно связаны между собой. Основными их опциями являются:

  • -i (от install — не путать с дополнительной опцией режима запроса) установка пакета, отсутствующего в системе;
  • -F обновление установленного пакета до более «свежей» версии;
  • -U обобщённая опция установки и обновления: при её использовании установленный пакет будет обновлён, а не установленный — инсталлирован.

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

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

Ранее я уже говорил, что утилита rpm не просто устанавливает пакеты, но и проверяет их зависимости. Хотя, с сожалению, не разрешает их, а только рапортует о нарушениях. Например, попытка «в лоб» установить kdebase

rpm -ihv http://mirror.yandex.ru/fedora/linux/releases/14/Fedora/x86_64/os/Packages/kdebase-4.5.2-2.fc14.x86_64.rpm

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

Retrieving http://mirror.yandex.ru/fedora/linux/releases/14/Fedora/x86_64/os/Packages/kdebase-4.5.2-2.fc14.x86_64.rpm
error: Failed dependencies:
	kdebase-libs(x86-64) = 6:4.5.2-2.fc14 is needed by kdebase-6:4.5.2-2.fc14.x86_64

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

Бывают ситуации более иные: вроде бы простой пакет при попытке установки требует как зависимость другой. А тот, в свою очередь, отказывается устанавливаться, так как ссылается на отсутствие первого. Так, давеча, затеяв апгрейд одной из экспериментальных своих систем до «сыромятной» (rawhide) версии, я столкнулся с тем, что пакет fedora-release-rawhide-15-0.3.noarch.rpm ни в какую не желал устанавливаться без fedora-release-15-0.3.noarch.rpm — и наоборот.

Вот в таких-то случаях и требуется указание всех взаимозависимых пакетов в качестве аргументов одной команды:

# rpm -ivh http://URL/path2/{fedora-release-15-0.3.noarch.rpm,
	fedora-release-rawhide-15-0.3.noarch.rpm}

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

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

К основным опциям установки и обновления полагается ещё много дополнительных опций, но за ними, как всегда, к тёте Мане.

Режим удаления…

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

# rpm -e pkgname

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

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

error: Failed dependencies:

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

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

Репозитории

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

Что такое репозиторий

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

В переводе на русский язык слово репозиторий означает хранилище — и именно его рекомендуют употреблять языковые пуристы (они же те, кто предпочитает называть себя grammar nazi). Однако, как это обычно бывает по жизни, в народе утвердилось иное их именование — repo или, говоря по нашему, по бразильскому кириллическому, репы. Почему во множественном числе — станет понятно из дальнейшего рассказа. Ну а как синоним я предпочитаю термин хренилищще.

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

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

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

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

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

Физическая структура репозиториев

Физически репозитории Fedora — это набор вложенных подкаталогов на ftp- или http-серверах, и имеют они подчас довольно сложную и не вполне прозрачную структуру. Знание её для пользователя не обязательно — но в ряде нештатных ситуаций будет не лишним. А поскольку структура эта нигде не описана, по крайней мере, на русском языке, — уделим ей толику внимания.

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

Структура главного репозитория

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

нет, не туда, куда вы подумали в меру своей испорченности, а на наиболее быстрое зеркало. Причём именно наиболее быстрое физически и именно в данный момент — потому что это проверяется не по зональной принадлежности и прочим формальным признакам, а по отклику на всамделишний запрос. Если, конечно, установлен соответствующий плагин к yum‘у — но об этом мы поговорим несколько позднее.

Так что, набрав в строке браузера что-нибудь типа http://download.fedoraproejct.org, наш советский пользователь окажется на сервере с URL типа http://mirror.имя_рек.ru/fedora/linux/ (а возможно, что даже и не ru вовсе). Имя этого самого имя река я изрекать не буду — полный список возможных вариантов можно увидеть здесь http://mirrors.fedoraproject.org/publiclist. И отдать предпочтение какому-то одному из них — значит, как сказал бы Шурик, проявить несправедливость к другому имя реку.

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

Итак, оказавшись на имя_рек/fedora/linux/, мы видим следующие каталоги:

development/
releases/
updates/

Как нетрудно догадаться, в каталоге development помещаются пакеты, находящиеся в состоянии разработки (здесь важен подкаталог /development/rawhide/, к которому мы со временем вернёмся), в каталоге updates — недавно обновлённые. А вот каталог releases — это именно то, что нас в данный момент интересует.

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

12
13
14

и подкаталог test. Иногда он пуст, содержимое в нём появляется, когда от разрабатываемой ветки (той самой rawhide) отщепляется альфа-версия следующего релиза.

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

Everything
Fedora
Live

Первый включает в себя пакеты различных версий и сборок, произведённых за время существования релиза. Первый, как следует из названия, содержит текущие обновления сборок пакетов, а последний — образы LiveCD для обеих поддерживаемых архитектур (i686 и x86_64). И о том, и о другом будет говориться своевременно. А вот по каталогу Fedora будем карабкаться дальше — тем более, что его можно рассматривать как пример устройства любого каталога на серверах проекта.

Итак, в каталоге fedora/linux/releases/14/Fedora/ можно видеть такие подкаталоги:

i386
source
x86_64

Второй из них включает в себя rpm-пакеты исходных текстов (так называемые *.src.rpm), о которых также речь пойдёт отдельная. Первый же и третий содержат сборки для 32- и 64-битных архитектур, соответственно. Очевидно, что внутри они абсолютно одинаковы, поэтому их внутренности рассмотрим на примере более актуальной ныне архитектуры x86_64.

iso
jigdo
os

В первом лежат образы установочных дисков — DVD, набора CD и диска для сетевой установки (netinst), о которых речь будет в разделе про установку системы. Второй содержит файлы метаданных для jigdo (Jigsaw Download) — системы распространения больших файлов (в данном случае — образов тех же установочных дисков) и служит той же цели, что и предыдущий. Ну а в третьем, в подкаталоге Packages, собственно, и находятся искомые пакеты.

Кроме этого, в каталоге fedora/linux/releases/14/Fedora/x86_64/os/ можно видеть служебные файлы, такие, как GPG-ключи для проверки подлинности, файлы описания репозитория (в подкаталогах repodata и repoview), файлы для компоновки собственных образов загрузочных дисков (в подкаталогах images и isolinux), которые в данный момент нас не интересуют.

Что же касается содержимого каталога Packages, то оно представлено rpm-пакетами — теми, которые непосредственно поддерживаются в рамках проекта Fedora.

Структура репозитория RPMFusion

Головным репозиторием, однако, список доступных для нашего дистрибутива пакетов не исчерпывается. Существует также репозиторий для дополнительных пакетов, поддерживаемых волонтёрами в рамках самостоятельного проекта — RPMFusion.

Собственно репозиторий дополнительных пакетов находится здесь. В нём мы видим два каталога — free и nonfree. Первый предназначен для безусловно свободных программ (в головном репозитории Fedora, кстати, только такие и имеются), второй — для программ, на распространение которых накладываются некоторые ограничения. Какие именно — к этому вопросу мы ещё вернёмся.

Внутренняя структура обоих каталогов одинакова. В них имеются подкаталоги el и fedora. Первый включает пакеты, обратно перенесённые (backports) из RHEL и нас сейчас не интересует. Второй же включает подкаталоги:

development/
releases/
updates/

а также файлы описания репозитория.

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

i386/
source/
x86_64/

Далее вглубь (или вверх? — зависит от используемой метафоры) — последний уровень вложенности — подкаталоги:

debug/
os/

В первом, как легко догадаться, — отладочная информация, которая нам сейчас не интересна. А вот во втором — уже собственно пакеты. В том числе и основной пакет описания репозитория — rpmfusion-free-release. Тот самый, установка которого однозначно приводит к подключению этой «репы». А в соответствующем подкаталоге каталога nonfree аналогичный пакет и будет именоваться соответственно — rpmfusion-nonfree-release.

Структура репозитория RFRemix

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

Он расположен в одноименном каталоге по следующему адресу (насколько я знаю, пока единственному). И структура его следующая: на первом уровне вложенности идут подкаталоги

  • build/ с файлами описания репозиториев,
  • releases/ с образами установочных дисков и LiveCD, и
  • russianfedora/, содержащий собственно пакеты.

В данный момент нас интересует только последний подкаталог. Он включает три подкаталога:

  • fixes/, представляющий своего рода дельту между базовыми и дополнительными пакетами оригинальной Fedora, с одной стороны, и RFRemix — с другой;
  • free/, предназначенный для полностью свободных пакетов проекта Russian Fedora;
  • nonfree/, предназначенный для пакетов проекта Russian Fedora, распространение которых ограничено законами некоторых стран (но не нашей).

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

Она идентична: каждый из них включает подкаталоги el/ и fedora/ того же назначения, что и в RPM Fusion. В подкаталоге fedora/, в свою очередь, выделяются подкатлоги development/, releases/ и updates/, а в подкаталоге releases/ — каталоги для номеров главных (мажорных) релизов, в настоящий момент — с 10-го по 15-й.

В каталоге каждого релиза мы видим единственный подкаталог Everything/, включающий подкаталоги для обеих поддерживаемых архитектур — i386/ и x86_64/, и подкаталог source/ для пакетов с исходными текстами. Ну и наконец этажом ниже лежат подкаталоги debug/ и os/ понятного (то есть того же, что и в RPM Fusion) назначения.

Дополнительные репозитории

Описанных выше репозиториев большинству пользователей хватит почти на все случаи жизни. Однако в ряде случаев возникает и необходимость в дополнительных пакетах, в официальные «репы» по тем или иным причинам не включённых — возможно, пока не включённых. Типичный на сегодняшний день пример — браузер Chromium: его не найти ни в RPM Fusion, ни в Russian Fedora.

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

Структура репозитория Fedora People предельно проста: по указанному адресу вы увидите множество каталогов, имена которых повторяют названия содержащихся в них пакетов. Внутри любого из них будет серия подкаталогов для поддерживаемого диапазона релизов — разного в разных случаях. А подкаталог каждого релиза содержит три стандартных подкаталога — i386/, SRPMS/ и x86_64/, заключающих в себе файл описания репозитория и собственно файлы пакетов.

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

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

В статьях и обзорах, посвящённых Fedora, можно встретить упоминания о многих других дополнительных репозиториях для этого дистрибутива — их список можно видеть, например, в ссылках с того же ATrpms. Однако практически все они потеряли актуальность. Одни (Livna, Freshrpms, Dribble) ныне объединены в составе RPM Fusion. В других содержатся пакеты для весьма старых версий Fedora. Ну а репозиторий Tigro стал основой для Russian Fedora — хотя ленивым обладателям старых версий Fedora он будет полезен и сам по себе.

Логическая организация репозиториев

Физическая структура репозиториев Fedora, особенно головного, выглядит довольно запутанной. К счастью, пользователю, как уже говорилось, практически не приходится иметь с ней дело. В 99 случаях их 100 ему достаточно ориентироваться в логической их организации, которую мы сейчас и рассмотрим.

Классификация программ

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

Первая категория называется free и охватывает программы, распространяемые безоговорочно свободно — то есть под лицензией GPL и, по мнению FSF, стопроцентно с ней совместимыми.

Вторая категория называется nonfree — название не очень удачное, поскольку вызывает ассоциации со всякого рода варезом, контрафактом или необходимостью каких-либо платежей при их использовании. На самом деле это совершенно не так. В категории nonfree объединены исключительно бесплатные (в смысле free beer) и легально распространяемые программы. Однако на распространение их накладываются те или иные ограничения. И потому с точки зрения FSF они не могут называться истинно свободными (в смысле free word).

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

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

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

Основные репозитории

Для начала рассмотрим основные репозитории, которые автоматически подключаются при установке RFRemix.

Главный, официально поддерживаемый, репозиторий проекта Fedora содержит только пакеты категории free. И поэтому называется просто и незатейливо — fedora, с расшифровкой в виде номера версии и целевой архитектуры, например: Fedora 15 — x86_64.

А вот в составе RPMFusion имеются как полностью свободные, так и «несвободные» пакеты. А потому в нём обособляются два репозитория — rpmfusion-free и rpmfusion-nonfree.

Внутреннее устройство Russian Fedora ещё «богаче» — в нём имеется целых три репозитория:

  • russianfedora-fixes — это пакеты, которые имеются в репозиториях fedora или rpmfusion, однако представленные версиями либо более новыми, либо адаптированными к нашим условиям и кириллическому окружению; пакеты этого репозитория не разделяются на свободные и несвободные;
  • russianfedora-free — полностью свободные пакеты, отсутствующие в репозиториях fedora или rpmfusion;
  • russianfedora-nonfree — «не совсем свободные», в указанном на прошлой странице смысле, пакеты, также отсутствующие в репозиториях оригинальной Fedora.

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

  • updates — для собственно Fedora;
  • rpmfusion-free-updates — для Rpmfusion-free;
  • rpmfusion-nonfree-updates — для rpmfusion-nonfree;
  • russianfedora-fixes-updates — для Russian Fedora Fixes;
  • russianfedora-free-updates — для Russian Fedora Free;
  • russianfedora-nonfree-updates — для Russian Fedora Nonfree.

Кроме того, каждому из основных репозиториев соответствуют специальные ветки отлаживаемых и тестируемых пакетов: fedora-debuginfo и fedora-updates-testing, соответственно — для основного репозитория и образованные по образу и подобию — для всех остальных.

И, наконец, существует ветка репозиториев rawhide. Она содержит пакеты следующей, разрабатываемой в настоящий момент, версии дистрибутива и, естественно, включает в себя те же самые репозитории, что и в ветках стабиольных релизов: fedora-rawhide, rpmfusion-free-rawhide, rpmfusion-nonfree-rawhide и так далее.

Сказанное выше относилось к репозиториям бинарных пакетов для архитектур i386 и x86_64. Однако есть ещё и репозитории исходных текстов — fedora-source, rpmfusion-free-source и так далее.

Добавить комментарий