---

Назначение и возможности

RPM (Red Hat Package Manager) представляет собой средство поиска, загрузки и установки пакетов программ, а также получения информации об установленных пакетах и их удаления. Информация об установленных пакетах хранится в БД RPM. Портирован под AIX, IRIX, и другие виды Unix. Распространяется под лицензией GNU GPL.

Альтернативным способом установки является загрузка исходных текстов программы (обычно в виде архива tar) и самостоятельная конфигурация (configure, automake), компиляция и сборка (make), установка (make install) и настройка. Сервера я предпочитаю устанавливать именно так. Но при этом приходится помнить какой файл куда установился, иначе будут проблемы при обновлении или удалении программы. А теперь представьте установку сотни программ при обновлении операционной системы или приобретении нового компьютера!

Дистрибутив Red Hat Linux (и многие другие: SuSE, Mandrake, Caldera, TurboLinux) поставляется в виде набора из нескольких сотен программных пакетов в формате rpm, часть из которых может быть включена при установке. Дополнительные пакеты могут быть загружены и установлены в дальнейшем из дистрибутива или других источников. Сам RPM состоит в Red Hat 7.1 из пакетов:

• rpm (проверка пакета, установка, удаление, обновление, получение информации (формат строки форматирования), верификация файлов)
• rpm-build (создание, цифровая подпись)
• rpm-devel (библиотека для написания программ, умеющих работать с пакетами)
• rpm-python (интерфейс с python, нужен для rhn_register, anaconda - реконфигурация системы)
• perl-Perl-RPM, переименован в rpm-perl (интерфейс с perl, никому не нужен ;)
• gnorpm (графический интерфейс для работы с пакетами для gnome)
• kdeadmin (графический интерфейс для работы с пакетами для KDE)
• rpmdb-redhat-7.1 (база данных всех пакетов, поставляемых с RH 7.1)
• rpmfind (поиск пакета в специальной базе данных в интернет)
• up2date (каждые 2 часа запрашивает Red Hat Network и устанавливает новые версии имеющихся пакетов)
• rpm2html (извлекает из набора пакетов информацию об их взаимозависимостях и преобразует ее в HTML и RDF)
• rpmlint (нахождение ошибок в пакетах, требуется rpm-python)
• другие программы

rpm контролирует зависимость одного пакета от другого при установке и удалении пакетов. Обеспечивается за счет того, что разработчик пакета определяет "возможность" (capability), которую реализует пакет, и список возможностей, требуемых для его работоспособности от других пакетов. В принципе, возможность представляет собой произвольно назначаемую текстовую строку и требует согласованной работы разработчиков различных пакетов. Довольно часто в качестве строки выбирается базовое имя разделяемой библиотеки (.so) или имя пакета. Пакет может включать триггеры - процедуры, выполняемые при установке или удалении других пакетов.

Существуют и системы управления пакетами - например, debian dpkg или SunOS pkgadd.

RPM определяет формат оформления пакета и формат базы данных установленных пакетов. Текущая версия - 4 (версии несовместимы по формату, форматы БД иногда даже несовместимы вниз). Правила работы rpm определяются конфигурационными файлами rpmrc.

Формат пакета

Пакет состоит из архива файлов и метаданных, включающих описательную информацию о пакете и его зависимостях, аттрибуты файлов и вспомогательные скрипты (увидим ли мы вирусы для .rpm? :0). Пакеты делятся на исполняемые (binary), содержащие программы для установки на пользовательский компьютер, и исходные (source), содержащие исходный текст и рецепт изготовления из него бинарного пакета.

Исполняемый пакет представляет собой один файл (общепринятый суффикс - .rpm), включающий архив программ, документации и конфигурационных файлов в формате cpio (формат SVR4 с CRC, архивированный gzip), описательные тэги и контрольные суммы/подписи. Для чтения архива и тэгов пакета подходит mc (не надо смущаться нулевой длиной тэгов в директории INFO; при нажатии на файлы INSTALL и UPGRADE происходит именно то, о чем вы подумали). Извлечь архив из пакета можно командой rpm2cpio (или тем же mc).

Исходный пакет служит для автоматического построения исполняемых пакетов (возможно для различных платформ и операционных систем) и также представляет собой один файл (общепринятый суффикс - .src.rpm), включающий архив в формате cpio (формат SVR4 с CRC, архивированный gzip), описательные тэги и контрольные суммы/подписи. Архив cpio содержит архив материалов от автора программы (обычно в виде .tar.gz), набор заплаток от сборщика пакета и спецификацию (spec) для автоматического процесса создания исполнямого пакета (распаковка архива, наложение заплаток, компиляция, сборка, уборка мусора и т.д.). Материалы от автора программы могут быть как исходными текстами, так и объектными модулями или готовыми программами, а также включают вспомогательные файлы для построения программы (configure, Makefile и др. в зависимости от предпочтений автора программы).

Имя файла, содержащего пакет имеет следующую структуру:
   метка_пакета.архитектура.rpm
где метка_пакета это
   имя_программы-версия_программы-версия_пакета

Архитектура выбирается из (полный список в /usr/lib/rpm/rpmrc):

• src (исходные тексты с инструкциями по построению пакета)
• nosrc (только инструкции по построению пакета)
• noarch (пакет не зависит от архитектуры: документация, скрипты)
• i386/i486/i586/i686
• sparc
• alpha
• ppc
• ...

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

Тэги пакета

Для пакета целиком может храниться информация (в скобках приведены имена тэгов, см. /usr/include/rpm/rpmlib.h):

• архитектура (ARCH, массив EXCLUDEARCH, массив EXCLUSIVEARCH)
• размер несжатого cpio архива пакета (ARCHIVESIZE)
• хост, на котором собран пакет (BUILDHOST)
• (BUILDROOT)
• время сборки (BUILDTIME)
• (CHANGELOGNAME, CHANGELOGTEXT, CHANGELOGTIME)
• лицензия (COPYRIGHT или LICENSE)
• место по умолчанию для перемещаемого пакета и реальное место (PREFIXES, INSTALLPREFIX)
• подробное описание программы (DESCRIPTION)
• имя продукта, в который входит пакет (DISTRIBUTION)
• иконка (GIF, ICON, XPM)
• классификация пакета: группа и подгруппа (GROUP)
• время установки пакета (INSTALLTIME)
• название пакета (NAME)
• под какую ОС собран пакет (OS, массив EXCLUDEOS, массив EXCLUSIVEOS)
• сборщик пакета (PACKAGER)
• имена файлов с заплатками для .src.rpm (массивы PATCH, NOPATCH)
• скрипт, выполняемый после установки (POSTIN, POSTINPROG)
• скрипт, выполняемый после удаления (POSTUN, POSTUNPROG)
• скрипт, выполняемый перед установкой (PREIN, PREINPROG)
• скрипт, выполняемый перед удалением (PREUN, PREUNPROG)
• обеспечиваемые пакетом возможности (массив PROVIDES)
• версия пакета для данной версии программы (RELEASE)
• флаги, определяющие как пакет зависит от возможностей других пакетов, например, версия не ниже указанной (массивы CONFLICTFLAGS, REQUIREFLAGS)
• требуемые пакетом возможности (массивы CONFLICTNAME, REQUIRENAME)
• версии возможностей, требуемых пакетом с учетом CONFLICTFLAGS или REQUIREFLAGS (массивы CONFLICTVERSION, REQUIREVERSION)
• версия и модификация RPM (RPMVERSION)
• (ROOT)
• (SERIAL, EPOCH)
• суммарный размер (в байтах) всех файлов пакета (SIZE)
• имена архивов с исходниками для .src.rpm (массивы SOURCE, NOSOURCE)
• имя пакета с исходными текстами (SOURCERPM)
• краткое описание программы (SUMMARY)
• (TRIGGERCONDS, TRIGGERFLAGS, TRIGGERINDEX, TRIGGERNAME, TRIGGERSCRIPTPROG, TRIGGERSCRIPTS, TRIGGERTYPE, TRIGGERVERSION)
• ссылка на дополнительную информацию (URL)
• распространитель пакета (VENDOR)
• скрипт верификации пакета (VERIFYSCRIPT, VERIFYSCRIPTPROG)
• версия программы (VERSION)
• контрольная сумма MD5
• PGP-подпись

Для каждого файла в пакете описаны (в скобках приведены имена тэгов):

• тип файла: документация, конфигурационный файл, другое (FILEFLAGS)
• текст символьной ссылки (массив FILELINKTOS)
• контрольная сумма MD5 (массив FILEMD5S)
• права доступа к файлу (массив FILEMODES)
• время последней модификации файла в момент сборки пакета (FILEMTIMES)
• имя и путь установки (массив FILENAMES)
• major/minor для специальных файлов устройств (массив FILERDEVS)
• размер файла (массив FILESIZES)
• состояние файла: normal, replaced другим пакетом, not installed, net shared (массив FILESTATES)
• владелец и группа (массивы FILEUIDS, FILEGIDS)
• владелец и группа в символьном виде (массивы FILEUSERNAME, FILEGROUPNAME)
• (массив FILEVERIFYFLAGS)
• содержимое файла

Формат базы данных

База данных пакетов обычно хранится в директории /var/lib/rpm (несколько файлов в формате Berkley DB3, в предыдущей версии был формат db1 и суффикс .rpm, так что открыть старую БД в новой системе не получается (hint: попробуйте rpm --define '_dbapi 1'). Имя директории может быть изменено ключом --dbpath путь или командой dbpath в конфигурационном файле /usr/lib/rpm/rpmrc (его имя может быть изменено ключом --rcfile путь).

Если БД слегка испортилась, то ее можно попытаться восстановить командой:
   rpm --rebuilddb

При установке Red Hat Linux имеется возможность установить пакет rpmdb-redhat-7.1, который представляет собой базу данных всех пакетов, входящих в дистрибутив RH 7.1 и ставится (30MB!) в /usr/lib/rpmdb/i386-redhat-linux/redhat.

Поиск пакетов

Для начала надо посмотреть на дистрибутивных дисках - нет ли там чего полезного. Затем сходить на сайт изготовителя дистрибутива - не выпустил ли он обновление нужного пакета. Например, на сайте Red Hat есть поиск пакетов по name, summary, description, именам файлов.

Если вы знаете название пакета, обеспечиваемого ресурса, имя разделяемой библиотеки или полное имя файла, то можно воспользоваться поиском пакета на rpmfind.net (бывший rufus.w3.org). Имеются также индексы rpm2html (категории, дистрибутивы, поставщики, дата создания, имя). Там же можно взять и сам пакет. Пакеты появляются в хранилище раньше, чем информация о них на сайте. И похоже, что некоторые дистрибутивы не включаются в БД вовсе (например, sourceforge), но их всегда можно просмотреть вручную по адресу http://rpmfind.net/linux/. Базу данных в формате RDF можно скопировать к себе для локального поиска (190 MB ;). Или взять с помощью wget хотя бы fullIndex.rdf.gz и положить его в ~/.rpmfinddir для rpmfind (сделать это самостоятельно у rpmfind не хватает терпения). В этом файле можно делать поиск по полям name и summary. Да мало ли что можно найти среди нескольких сотен гигабайт! К сожалению, это число надо делиь на 10, так как один и тот же пакет встречается во множестве вариантов. ISO-образы отдает только, если вы можете обеспечить скорость загрузки не менее 100 KB/sec. Файлы отдаются по FTP, HTTP и rsync.

Основные зеркала: fr.rpmfind.net, fr2.rpmfind.net, speakeasy.rpmfind.net. Полный список зеркал (точнее сайтов, использующих технологию rpm2html, так как состав БД на зеркалах может отличаться) приведен здесь. Особенно хочется отметить http://rpmfind.userfriendly.net, содержащий более 200 ГБ rpm, в том числе sourceforge.

Пакеты, собранные специально под Red Hat можно найти на freshrpms или rhcontrib или GNOME hide или falsehope (каково название ;).

Каталог программ (17 тысяч проектов) для Unix можно найти на freshmeat.net (OSDN - VA Software).

Полезно заглянуть на "пристанище" открытых проектов SourceForge (также OSDN - VA Software).

Утилита rpmfind

Утилита rpm2html

Если у вас есть опыт установки пакетов, то вы должно быть уже знакомы с сообщением:
   error: failed dependencies:
      libsuperpuper.so.10 is needed by super-1.5-4
Иногда (и очень даже часто) из такого сообщения трудно понять как называется пакет, который предоставляет эту libsuperpuper.so.10? А когда его найдешь, то оказывается, что он тоже требует какой-то библиотеки и так далее (как-то раз я дошел до 5-го "уровня вложенности" после чего решил, что мне эта программа нужна не так уж сильно ;0).

rpm2html позволяет строить набор HTML-страниц и RDF-базу с описанием пакетов и их взаимозависимостей из набора пакетов. Это облегчает поиск пакетов, которые необходимо установить перед установкой требуемого вам пакета, если они входят в один набор (например, один и тот же дистрибутив). Результат работы rpm2html используется как командой rpmfind, так и сайтом rpmfind.net (http://rpmfind.net/linux/RPM/). Строится список пакетов, отиндексированный по категориям, дистрибутивам, поставщикам, дате создания, именам пакетов. Для каждого пакета создается отдельная страница, содержащая информацию из основных тэгов, список ресурсов которые пакет предоставляет и которые он требует. Упоминание каждого ресурса является ссылкой на посвященную ему страницу, на которой указано какой пакет(ы) его предоставляет. К сожалению, нет обратных ссылок (какие пакеты данный ресурс требуют) и индекса ресурсов.

Входящий в состав Red Hat 7.1 пакет rpm2html-1.5 требует наличия mysqlclient (знакомая песня!), поэтому я предпочел собрать его из исходных текстов. Загружаем (версии 1.6 и 1.7 не собираются в RH7.1, хотят xml2), распаковываем архив, autoconf, ./configure, make, make install (в /usr/local), редактирование /usr/local/etc/rpm2html.config, создание директории для результатов, запуск:
   rpm2html конфигурационный_файл

Конфигурационный файл состоит из

• секции глобальных параметров
  • maint=имя администратора
  • mail=почтовый адрес администратора
  • html=true или false (делать ли html-страницы)
  • dir=имя директории для результатов
  • url=относительный URL директории результатов
  • rdf=true или false (делать ли RDF-базу данных)
  • rdf_dir=имя директории для RDF
  • rdf_resources=true или false (делать ли список ресурсов в RDF-формате)
  • rdf_resources_dir=имя директории для них
  • tree=true или false (делать ли дерево директорий)
• отдельная секция для каждой директории, все директории обрабатываются совместно, секция начинается с метки директории в квадратных скобках
  • name=имя директории
  • color=цвет в формате #RRGGBB (ссылки на пакеты из этой директории будут помечены этим цветом)
  • subdir=local
  • ftp=URL, откуда можно загрузить пакеты (FTP, HTTP, file)
  • ftpsrc=URL, откуда можно загрузить исходные пакеты
  • url=часть url из глобальной секции, относящаяся к данной директории
  • mirror=зеркало для загрузки пакетов

Например, секция для локально установленных пакетов выглядит так (метка localbase зарезервирована для этого случая):

[localbase]
name=Installed RPMs in default base
color=#e0ffe0
subdir=local
ftp=ftp://ftp.redhat.com/pub/redhat/redhat-7.1/i386/RedHat/RPMS
ftpsrc=ftp://ftp.redhat.com/pub/redhat/redhat-7.1/SRPMS

Проверка пакетов из командной строки

Перед установкой загруженного из интернет файла полезно его проверить. Команда
   rpm --checksig [-vv]имя_файла[ имя_файла...]
проверяет контрольную сумму MD5 (отключается ключом --nomd5), подпись PGP (отключается ключом --nopgp) и подпись GnuPG (отключается ключом --nogpg). Прежде чем проверять подписи PGP и GnuPG необходимо установить соответствующие системы и импортировать (gpg --import имя-файла) и заверить публичные ключи поставщика пакета. Как минимум, команда должна ответить:
   имя_файла: md5 OK
а лучше
   имя_файла: md5 gpg OK
иначе вам попался "битый" или - хуже того - подделанный пакет.

Информация о ключе Red Hat приведена на их сайте (Red Hat, Inc ).

Установка пакетов из командной строки

В простейшем случае установка пакета производится командой
   rpm -i имя_файла[ имя_файла...]

Вместо имени файла можно указывать URL (в этом случае используются также ключи: --ftpproxy host, --ftpport proxy-port, --httpproxy host, --httpport proxy-port). Если указано имя пользователя, но опущен пароль, то он запрашивается интерактивно(это позволяет не светить пароль в командной строке и на экране). FTP используется в пассивном режиме (PASV).

Перед установкой пакета проверяется наличие места в файловой системе (какой?) (обходится ключом --ignoresize). Пакеты упорядочиваются так, чтобы зависимый пакет устанавливался после того, от которого он зависит (отменяется ключом --noorder). При установке проверяются зависимость устанавливаемого пакета от наличия других пакетов (обходится ключем --nodeps), отсутствие конфликтов с ранее установленными пакетами (пакет уже был установлен - обходится ключем --replacepkgs; ранее была установлена более свежая версия пакета; один из файлов с требуемым именем уже существует - обходится ключем --replacefiles, предыдущая версия конфигурационного файла сохраняется с суффиксом .rpmsave, будут проблемы при удалении конфликтующего пакета), выполняются предустановочные скрипты (отменяются ключами --noscripts, --nopre), пытается обновить конфигурационные файлы (предыдущая версия файла может сохраняться с суффиксом .rpmorig; интересно, что происходит, если и эти имена заняты?), распаковываются файлы и распихиваются по нужным местам с установкой владельца и прав доступа, запускаются постустановочные скрипты (отменяются ключами --noscripts, --nopost), запускаются триггеры, определенные в других пакетах (отменяются ключами --notriggers, --notriggerin), обновляется база данных установленных пакетов.

Ключ --test (--nobuild) позволяет проверить возможность установки пакета без реальной установки. Ключ -vv позволяет вывести множество информации в процессе установки.

Ключ --force позволяет обойти все проверки при установке пакета, кроме проверки зависимости от других пакетов.

Ключ --prefix путь позволяет установить пакет в нужную директорию, если пакет переместим (relocatible). Стандартная директория переместимого пакета определяется по команде
   rpm -qp --queryformat "%{prefixes}\n" имя_файла
Ключ --relocate старый_путь=новый_путь заменяет старый_путь на новый_путь в именах файлов переместимого пакета. Ключ --badreloc в сочетании с --relocate делает то же самое для непереместимого пакета (надеюсь, что вы уверенно держите в руках напильник для последующей рихтовки, т.е. расстановки символьных ссылок ;).

При загрузке со спасательной дискеты полезен ключ --root путь, который определяет корень файловой системы для устанавливаемых пакетов (в т.ч. выполняется chroot() при запуске пред- и постустановочных скриптов) и базы данных пакетов.

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

Удаление пакетов из командной строки

В простейшем случае удаление пакета производится командой
   rpm -e имя_пакета[ имя_пакета...]

При удалении пакета проверяется, что нет пакетов, зависящих от удаляемого (обходится ключем --nodeps); что имеется только одна версия указанного пакета (обходится ключем --allmatches); выполняется подготовительный скрипт (отменяются ключами --noscripts, --nopreun); если конфигурационный файл был изменен, то создается его копия (с суффиксом .rpmsave); удаляются все принадлежащие пакету файлы, если они не принадлежат другому пакету; выполняется завершающий удаление скрипт (отменяются ключами --noscripts, --nopostun); выполняются триггер-скрипты, активируемые удалением пакета (отменяются ключами --notriggers, --notriggerun, --notriggerpostun); обновляется база данных установленных пакетов.

Ключ --test позволяет проверить возможность удаления пакета без реального удаления. Ключ -vv позволяет вывести множество информации в процессе удаления.

Ключ --repacked позволяет собрать удаляемые файлы в пакет (/var/tmp).

При загрузке со спасательной дискеты полезен ключ --root путь, который определяет корень файловой системы для удаляемых пакетов (в т.ч. выполняется chroot() при запуске пред- и пост- скриптов) и базы данных пакетов.

Обновление пакетов из командной строки

В простейшем случае обновление пакета производится командой
   rpm -[U|F] имя_файла[ имя_файла...]

Вместо имени файла можно указывать URL (в этом случае используются также ключи: --ftpproxy, --ftpport, --httpproxy, --httpport). Если указано имя пользователя, но опущен пароль, то он запрашивается интерактивно(это позволяет не светить пароль в командной строке и на экране).

Фактически сначала устанавливается новая версия пакета, затем удаляется старая версия. Оба процесса описаны выше. Только конфигурационные файлы обрабатываются в зависимости от совпадения старого, текущего и нового содержимого (текущий файл может быть переименован с суффиксом .rpmsave, если файл принадлежал старой версии пакета, или с суффиксом .rpmorig, если файл был "самодельным"). Ключи --force, --replacepkgs, --prefix путь, --relocate, --badreloc, --ignoresize, --notriggers, --excludepath путь, --excludedocs, --noorder, --replacefiles, --noscripts (действует только на установку!), --test, -vv, --nodeps, --root путь также работают как описано выше.

Если предыдущая версия пакета не была установлена, то происходит обычная установка пакета при использовании ключа -U или пропуск пакета при использовании ключа -F.

Ключ --oldpackage позволяет вернуться к предыдущей версии пакета.

Получение информации о пакетах из командной строки

Синтаксис команды:
   rpm -q выбор_пакета выбор_информации

Ключи выбора пакета:

• метка_пакета (описана выше; можно указать только имя)
• -a (все установленные пакеты)
• -f полное_имя_файла (пакет, которому принадлежит указанный файл; в пути не д.б. символьных ссылок)
• -p rpm-файл (вместо имени м.б. URL)
• -g класификационная_группа_и_подгруппа
• --whatprovides capability (пакеты, обеспечивающие указанную возможность)
• --whatrequires capability (пакеты, требующие указанную возможность)
• --specfile spec-файл (выдать информацию как-будто по spec файлу построен пакет)
• --triggeredby метка_пакета (пакеты, содержащие триггер-скрипты, активизируемые указанным пакетом)

Ключи выбора выводимой информации:

• --last (упорядочивает вывод таким образом, что установленный последним пакет показывается первым)
• -i (основная информация о пакете в "человеколюбивом" формате)
• -l (список файлов, ключ --filesbypkg упорядочивает файлы по пакетам)
• -lv (список файлов с подробной информацией)
• -c (список конфигурационных файлов)
• -d (список файлов с документацией)
• -s (выдается состояние каждого файла: normal, replaced другим пакетом, not installed, net shared)
• --provides (какие возможности обеспечивает пакет)
• --requires (какие возможности, пакеты или версии требует пакет)
• --changelog
• --dump (для каждого файла из списка - определяется ключом -l, -c или -d - выдается информация из БД
  • полное имя файла
  • размер файла
  • время последней модификации (в UNIX-формате)
  • MD5
  • права доступа (восьмеричное число)
  • владелец файла
  • группа файла
  • принадлежность к файлам конфигурации (0 или 1)
  • принадлежность к файлам документации (0 или 1)
  • major,minor для специального файла устройства, иначе 0
  • путь для символьной ссылки (иначе буква 'x')
• --scripts (какие скрипты пре- и постустановки, верификации, пре- и постудаления содержит пакет)
• --triggerscripts (какие триггерные скрипты содержит пакет))
• --queryformat строка_форматирования (формат выдачи информации)

Ключи -vv, --root путь, --dbpath путь работают как описано выше.

Строка форматирования

Строка форматирования (рекомендуется заключать в апострофы) может содержать литеральный текст (в т.ч. escape-последовательности \a, \b, \f, \n, \r, \t, \v, \\), тэги и итераторы.

Тэг определяет какая информация о пакете или файле будет выведена. Список тэгов (114 для rpm 4.0.2) можно получить командой (префикс RPMTAG_ можно опускать):
   rpm --querytags
Список наиболее употребимых тэгов приведен в разделе Формат пакета. Смотри также /usr/include/rpm/rpmlib.h (RPMTAG_...). Формат использования тега в строке форматирования:
   %[[-]мин_ширина_поля]{имя_тэга[:модификатор]}
где тире перед минимальной шириной поля вызывает выравнивание поля влево (по умолчанию - вправо).

Модификатор позволяет выводить некоторые данные в более читаемом виде:

• date (дата в человеческом формате: Tue Oct 22 19:39:09 1996)
• day (дата без времени: Tue Oct 22 1996)
• perms (права доступа в формате команды ls)
• depflags (флаги сравнения версий в виде условных операторов)
• fflags (выводит букву c для конфигурационных файлов, и букву d для файлов документации; s для spec-файлов; m для missingok; n для noreplace)
• octal
• hex
• shescape (при необходимости строки заключаются в апострофы и в выдачу вставляются escape-символы)

Если для пакета отсутствует определенный тэг, то вместо него будет выведена строка (none) или (unknown).

Некоторые тэги (например, FILENAMES) могут определять множество данных. Такие многозначные тэги д.б. заключены внутри итераторов. Итератор обозначается квадратными скобками. Чтобы поместить однозначный тэг внутри итератора, его имя предваряется знаком равенства. Число элементов в множестве можно вывести с помощью:
   %{#имя_тэга}

Примеры извлечения информации из БД установленных пакетов

Сортировка пакетов по занимаемому размеру
   rpm -qa --queryformat '%{NAME}: %{SIZE}\n'|sort -rn +1

Сортировка файлов по размеру
   rpm -qa --queryformat '[%{FILENAMES}: %{FILESIZES}\n]'|sort -rn +1

Скрипт make-pkg-list.sh для получения списков пакетов (необходимо предварительно установить пакет rpmdb-redhat):

• rpm.distr.list - полный список пакетов, входящих в состав дистрибутива
• rpm.installed.list - список, установленных пакетов
  в том числе:
  • rpm.orig.list - пакеты, текущая версия которых совпадает с версией в дистрибутиве
  • rpm.nonorig.list - пакеты, текущая версия которых не совпадает с версией в дистрибутиве или невходящие в дистрибутив
    в том числе
    • rpm.updated.list - пакеты, текущая версия которых не совпадает с версией в дистрибутиве
    • rpm.added.list - пакеты, невходящие в дистрибутив

Немного ;) более сложный скрипт make-file-list.sh, который позволяет отсортировать файлы установленных пакетов по типам (dir, file, link, pipe, rdev) и "нетронутости" (normal, nonexist, неправильный mtime, несовпадающая md5, неверные права доступа). Создается дополнительный список директорий, не упомянутых явно в БД пакетов. Используется дополнительная программа fileinfo.c.

Скрипт whowhat.sh для получения списка зависимостей между установленными пакетами.

Скрипт unrequired.sh для получения списка установленных пакетов, от которых не зависит ни один другой пакет (особенно умиляет наличие в этом списке пакета bdflush, и ведь удалится без предупреждения!). Используется whowhat.sh и /usr/local/bin/count.awk.

Верификация установленного пакета из командной строки

Верификация (ключ -V) включает проверку зависимости пакета от возможностей, предоставляемых другими пакетами (отключается ключом --nodeps); выполнение верификационных скриптов, предоставляемых разработчиком пакета (отключается ключом --noscripts); проверку наличия всех файлов и их корректное состояние (отключается ключом --nofiles). Неинсталлированные (например, по ключу --excludedocs) файлы не проверяются. Требуется неповрежденная БД установленных пакетов.

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

• директория: права доступа, владелец, группа
• символьная ссылка: строка ссылки, права доступа (всегда 777), владелец (всегда root), группа (всегда root) - что тут проверять?
• FIFO: права доступа, владелец, группа
• устройство: права доступа, владелец, группа, major, minor
• обычный файл: размер, права доступа, владелец, группа, MD5, время модификации

При несовпадении атрибутов файла с записью в БД выдается строка вида (для совпадающего атрибута вместо буквы выводится точка; если невозможно произвести проверку, то выводится вопросительный знак)
   SM5DLUGT c имя_файла, где

• S - несовпадение размера
• M - несовпадение прав доступа или типа файла
• 5 - несовпадение MD5
• D - несовпадение major,minor
• L - несовпадение символьной ссылки
• U - несовпадение владельца
• G - несовпадение группы
• T - несовпадение времени модификации
• c - выводится, если файл относится к конфигурационным

Ключом --nomd5 отключается проверка MD5.

Ключи выбора пакета:

• метка_пакета (описана выше; можно указать только имя)
• -a (все установленные пакеты)
• -f полное_имя_файла (пакет, которому принадлежит указанный файл; в пути не д.б. символьных ссылок)
• -p rpm-файл (вместо имени м.б. URL; БД пакетов не используется)
• -g класификационная_группа_и_подгруппа
• --whatprovides capability (пакеты, обеспечивающие указанную возможность)
• --whatrequires capability (пакеты, требующие указанную возможность)
• --triggeredby метка_пакета (пакеты, содержащие триггер-скрипты, активизируемые указанным пакетом)

Восстановление прав доступа файлов по БД пакетов:
   rpm --setperms ключи_выбора_пакета

Восстановление владельца и группы файлов по БД пакетов:
   rpm --setugids ключи_выбора_пакета

Ключи -vv, --root путь, --dbpath путь работают как обычно.

gnorpm

gnorpm - графический интерфейс для работы с пакетами в Gnome (предыдущую аналогичную программу glint фирма redhat забросила).

Создание пакета: исходные материалы

Для создания исходного пакета требуется архив материалов от автора программы (желательно в формате .tar.gz), модифицирующие авторский материал заплатки (например, адаптация к целевой платформе, операционной системе, расположению файлов) и инструкции по процессу построения (spec file).

В состав пакета rpm входит скрипт gendiff, облегчающий создание заплаток. Достаточно перед модификацией файлов сохранить их исходные версии с определенным суффиксом (например .original), после чего выполнить команду:
   gendiff директория .original > имя-заплатки

По обычаю, при работе используются поддиректории /usr/src/redhat:

• BUILD (сюда распаковываются исходники и здесь делается компиляция и линковка)
• RPMS (здесь создаются бинарные пакеты: отдельная директория для каждой архитектуры)
• SOURCES (исходники, заплатки, иконки)
• SPECS (spec-файлы)
• SRPMS (здесь создаются исходные пакеты)

Создание пакета: формат spec-файла

Структура spec-файла (точный формат легко извлекается из исходников rpm, а вы как думали ;):

• строка, начинающаяся с # является комментарием
• преамбула (описание пакета, версия и прочая информация, источники, заплатки, иконка):
  • Summary:
  • Name: (не может содержать пробел)
  • Version: (не может содержать пробел или тире)
  • Release: (не может содержать пробел или тире)
  • Copyright:
  • Group: (классификация пакета: группа и подгруппа через /; в комплект документации входит файл GROUPS с перечнем групп; пробелы допускаются)
  • Source: (URL, откуда взят авторский архив, простое имя файла используется как имя исходного файла в директории SOURCE; если исходных архивов два или более, то второй указывается тэгом source1 и т.д.)
  • nosource: (указанный - по номеру - исходный архив не помещается в исходный пакет; получив такой "неполный" пакет придется самому добывать отсутствующий архив и помещать его в SOURCES перед построением бинарного пакета)
  • patch: (URL, откуда взяты заплатки, простое имя файла рассматривается как имя файла с заплатками в директории SOURCES; если заплаток две или более, то вторая указывается тэгом patch1 и т.д.)
  • nopatch: (аналогично nosource для заплаток)
  • URL: (указатель на авторскую страницу с документацией)
  • Distribution: (имя продукта, в который входит пакет)
  • Vendor:
  • Packager:
  • icon: (GIF или XPM с прозрачным фоном, должен лежать в SOURCE)
  • provides: (виртуальная возможность, обеспечиваемая пакетом; имя пакета добавляется в список автоматически)
  • requires: (требуемые для установки пакета другие пакеты или виртуальные возможности; может быть с указанием требуемой версии/релиза (playmidi >= 2.3) или требуемого серийного номера (playmidi =S 4) )
  • conflicts: (противоположность тэгу requires, определяет пакеты и версии, несовместимые с данным пакетом)
  • obsoletes: (установка данного пакета вызывает удаление указанных пакетов)
  • serial: (epoch, используется для проверки зависимости пакетов, чья система нумерации версий не позволяет RPM делать сравнения)
  • autoreqprov: (значение no позволяет отменить автоматическую генерацию provides и requires на основе информации о созданных или требуемых разделяемых библиотеках)
  • excludearch: (список недопустимых архитектур через пробел или запятую)
  • exclusivearch: (строить пакет только для этих архитектур)
  • excludeos: (список недопустимых ОС через пробел или запятую)
  • exclusiveos: (строить пакет только для этих ОС)
  • prefix: (позволяет задать для переместимых пакетов начало полных имен файлов, которое может быть заменено на значение ключа --prefix при установке; каждое имя в %files должно начинаться с этого префикса; программа должна быть написана с учетом возможности установки в разные места (абсолютная ссылка на файл из этого же пакета - плохой признак); другие программы тоже д.б. готовы к этому)
  • prefixes: (позволяет задать несколько префиксов переместимых пакетов)
  • buildroot: корневая-директория-по-умолчанию (см. описание ключа --buildroot; только не используйте "/"!)
  • docdir: (установить другую директорию документации вместо /usr/share/doc)
• %package: строка (позволяет создавать несколько пакетов с помощью одного spec-файла; строка добавляется к имени базового пакета через дефис для образования имени подпакета (ключ -n позволяет явно задавать имя подпакета); строка, использованная как параметр секции (%description -n foo, %files, %pre, %post, %preun, %postun, %verifyscript), заставляет ее отрабатывать только для данного подпакета; указанные после %package тэги относятся только к данному подпакету (дублировать ранее определенную информацию не надо); исходный пакет получает тэги, установленные для главного пакета)
• %description (несколько строк с описанием; ключ -l позволяет задать язык)
• %prep (инструкции по предварительной подготовке: создание директории, распаковка, наложение заплаток, прочие подготовительные действия; представляет собой скрипт для shell; имеются макросы для распаковки .tar.gz (%setup) и наложения заплаток (%patch))
• %build (shell-скрипт для компиляции и сборки; обычно команда make)
• %install (shell-скрипт для установки файлов для бинарного пакета; обычно make install с указанием временной директории)
• %pre (shell-скрипт, исполняемый на пользовательском компьютере перед установкой бинарного пакета; доступна переменная RPM_INSTALL_PREFIX; в качестве параметра передается количество пакетов с данным именем, которые окажутся установленными в результате выполнения команды; вместо /bin/sh может использоваться другая программа, если она указана ключом -p)
• %post (скрипт, исполняемый на пользовательском компьютере после установки бинарного пакета)
• %preun (скрипт, исполняемый на пользовательском компьютере перед удалением бинарного пакета)
• %postun (скрипт, исполняемый на пользовательском компьютере после удаления бинарного пакета)
• %verifyscript (скрипт, исполняемый на пользовательском компьютере при верификации установленного пакета)
• %clean (shell-скрипт для очистки мусора после построения бинарного пакета; в большинстве случаев rpm делает это самостоятельно, но при использовании build root соответстующие директории надо чистить этим скриптом)
• %files (список полных путей файлов, составляющих пакет по одному на строке; отсутствие директивы %files - отсутствие пакета, пустой список в %files - построение пакета без файлов; при указании директории без директивы %dir rpm включит все файлы в указанной директории и ее поддиректориях; можно использовать shell-шаблоны; могут предваряться директивами через пробел; список можно читать из файла с помощью ключа -f имя-файла)
• %changelog
• %triggerin -- условие (условие задается как в requires:; если при установке некоего пакета условие выполняется, то запускается данный скрипт)
• %triggerun
• %triggerpostun

Скрипты %prep, %build, %install и %clean могут использовать следующие переменные окружения (их значения можно изменить в rpmrc):

• RPM_SOURCE_DIR (/usr/src/redhat/SOURCES; здесь лежат архивы, задаваемые тэгом source)
• RPM_BUILD_DIR (/usr/src/redhat/BUILD; сюда распаковываются исходники)
• RPM_DOC_DIR (/usr/share/doc; в старых версиях /usr/doc; сюда помещаются файлы по директиве %doc)
• RPM_OPT_FLAGS (опции передаваемые в make, устанавливаются директивами optflags: в файле rpmrc в зависимости от архитектуры)
• RPM_ARCH
• RPM_OS
• RPM_BUILD_ROOT
• RPM_PACKAGE_NAME, RPM_PACKAGE_VERSION, RPM_PACKAGE_RELEASE

Макрос %setup удаляет старое содержимое директории пакета в BUILD, распаковывает .tar.gz, устанавливает права доступа к файлам. Параметры (обычно используется при наличии нескольких исходных архивов):

• -n имя-директории-для-сборки (что записано в tar)
• -c (создает директорию верхнего уровня, если tar-архив ее не содержит)
• -D (не удалять директорию перед распаковкой; используется если вызывается несколько макросов %setup или используется несколько исходных архивов)
• -T (не распаковывать исходный архив; используется в сочетании с -b 0)
• -b номер (распаковывать указанный source до перехода в директорию)
• -a номер (распаковывать указанный source после перехода в директорию)

Макрос %patch накладывает заплатку (возможно, разхимая ее) на предварительно распакованные исходные тексты. Состоит из одной строки. Параметры:

• -P номер (накладывать указанную заплатку; можно просто написать: %patch3)
• -p чмсло (передается команде patch; обрезает верхние директории из путей к файлам)
• -b имя (использовать имя в качестве суффикса вместо стандартного .orig для немодифицированных копий файлов; полезен, если заплаток несколько)
• -E (передается команде patch; если после наложения заплатки файл опустел, то он удаляется)

Директивы %files:

• %doc (файл является частью документации; если имя файла не абсолютное, то при установке пакета создается директория /usr/share/doc/имя-версия-release и файл помещается в нее, иначе он размещается наравне с остальными файлами пакета)
• %docdir (по умолчанию считается что файлы из директорий /usr/share/doc, /usr/share/man и /usr/share/info являются документацией; директива %docdir позволяет расширить этот список; сами файлы надо указывать дополнительно)
• %config (файл является конфигурационным)
• %attr(mode, user, group[, dirmode]) (задает права доступа в восьмеричном формате, имя владельца и группы; не uid/gid; прочерк в любом поле означает не менять его значение)
• %defattr(mode, user, group) (определяет права доступа по умолчанию; прочерк в любом поле означает не менять его значение)
• %verify() (какие аттрибуты файла проверять при верификации установленного пакета; задаются в виде списка ключевых слов через пробел: owner, group, mode, md5, size, maj, min, symlink, mtime; отрицание обозначается ключевым словом not)
• %defverify()
• %dir (включить в пакет директорию без ее содержимого)
• %ghost (файл не включается в пакет, предполагается что создается %pre или %post скриптом и должен удаляться при удалении пакета)
• %lang()
• %dev(type,major,minor)

Условные операторы (могут быть вложены):

• %ifarch список-архитектур
• %ifnarch список-архитектур
• %ifos список-ОС
• %ifnos список-ОС
• %else
• %endif

В spec-файле можно использовать значения тэгов и пользовательских макросов в виде: %{имя}, а также значения директив rpmrc в виде %{_имя}. Значения макросам присваиваются командой:
   %define имя значение

Не надо вставлять вызов rpm в скрипты spec-файла.

Создание пакета

Последовательность действий при создании пакета:

1. выполнение команд и макросов в секции %prep
2. проверка содержимого списка файлов
3. выполнение команд и макросов в секции %build
4. выполнение команд и макросов в секции %install и макросов в списке файлов (при этом программа устанавливается на компьютер, используемый для сборки пакета)
5. создание бинарного пакета в /usr/src/redhat/RPMS/архитектура (зависимости пакета от других программ частично находятся автоматически исполнением ldd над каждой программой из пакета, что позволяет определить, какие разделяемые библиотеки используются в данном пакете (скрипт /usr/lib/rpm/find-requires))
6. выполнение команд и макросов в секции %clean
7. создание исходного пакета в /usr/src/redhat/SRPMS

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

Синтаксис команды (не забудьте перейти в /usr/src/redhat/SPECS):
   rpm -bфаза доп.ключи имя_spec-файла

Фаза позволяет выполнить не все шаги построения пакетов:

• p (только %prep)
• c (%prep и %build)
• i (%prep, %build, %install)
• b (%prep, %build, %install, создание бинарного пакета)
• s (%prep, %build, %install, создание исходного пакета)
• a (все шаги)
• l (проверить список в %files: что все файлы существуют, какие разделяемые библиотеки требуются исполняемым файлам из списка (/usr/lib/rpm/find-requires), какие разделяемые библиотеки обеспечиваются пакетом (/usr/lib/rpm/find-provides))

Дополнительные ключи:

• --short-circuit (выполнять только указанную фазу; только фазы c и i)
• --target архитектура-поставщик-ОС (строить пакет для указанной архитектуры и ОС, не обращая внимания на автораспознавание)
• --buildarch архитектура (строить пакет для указанной архитектуры; предпочтительнее использовать --target)
• --buildos OS (строить пакет для указанной ОС; предпочтительнее использовать --target)
• --sign (подписать создаваемые пакеты с помощью pgp или gpg, спрашивает парольную фразу)
• --test (вместо реального построения пакетов в директорию /var/tmp (можно изменить командой tmppath в rpmrc) записываются скрипты построения, отдельный скрипт для каждой фазы )
• --buildroot путь (позволяет задать корневую систему для фазы %install, это единственный способ для непривилегированного пользователя строить пакеты, также это позволяет не мусорить на сборочном компьютере; необходимы изменения в spec-файле; используемый программой метод установки должен выдерживать изменение корневой директории, предоставляется установленная переменная RPM_BUILD_ROOT, можно поменять %install, Makefile и т.д.; необходимо добавить в секцию %clean команды очистки; если нет прав суперпользователя, то необходимо создать свою иерархию директорий, аналогичную /usr/src/redhat, в доступном месте и задать в .rpmrc директиву topdir: полный-путь; если нет прав суперпользователя, то необходимо поменять процедуру установки, чтобы она не выполняла chown/chgrp, возместив это директивами %attr в секции %files; акуратнее: первая команда фазы %prep есть rm -rf $RPM_BUILD_ROOT ;)
• --timecheck секунд (предупреждать, если в пакет включаются слишком старые файлы - наверное, они от предыдущей сборки)
• --rmsource (удалить исходные архивы и spec-файл после построения пакета)

Использование вместо ключа -b ключа -t заставляет rpm извлекать spec-файл из tar-архива (возможно сжатого).

Сборка бинарного пакета из исходного (следы удаляются):
   rpm --rebuild исходный-пакет

Подпись пакета

Предварительно необходимо установить GnuPG и сгенерировать ключ (gpg --gen-key). В rpmrc/.rpmrc внести информацию о том, кто будет подписывать пакеты:

• signature: gpg (макро %_signature)
• gpg_name: идентификатор подписывающего (макро %_gpg_name)
• gpg_path: /home/.../.gnupg (макро %_gpg_path)

Подписать пакет можно:

• при построении ключом --sign
• переподписав пакет ключом --resign
• добавив подпись ключом --addsign

Конфигурационные файлы (rpmrc)

Везде где в данном тексте упоминался файл rpmrc, надо смотреть (или править) файлы ~/.rpmrc (наибольший приоритет), /etc/rpmrc или /usr/lib/rpm/rpmrc (наименьший приоритет). Каждый из этих файлов содержит директивы управления программами из пакета rpm.

Переназначить конфигурационный файл при вызове rpm можно ключом --rcfile путь.

Посмотреть значения директив конфигурации можно командой
   rpm --showrc

Некоторые директивы:

• builddir:topdir/BUILD
• buildroot:
• dbpath:/var/lib/rpm
• defaultdocdir:/usr/share/doc
• distribution:
• excludedocs:0
• ftpport:
• ftpproxy:
• gpg_name: (идентификатор владельца публичного ключа)
• gpg_path: (путь к .gnupg)
• messagelevel:3 (меньше число - больше информации)
• optflags: (зависит от платформы)
• packager:
• rpmdir:topdir/RPMS
• signature:
• sourcedir:topdir/SOURCE
• specdir:topdir/SPEC
• srcrpmdir:topdir/SRPMS
• timecheck: (секунд для --timecheck)
• tmppath:/var/tmp
• topdir:/usr/src/redhat
• vendor:

Макросы определяются в файлах /usr/lib/rpm/macros, /etc/rpm/macros и ~/.rpmmacros. Также могут определяться "на ходу" ключом --define "имя значение" (имя без процента). Посмотреть значение макроса можно ключом --eval '%{имя'}. Есть рекурсия подстановки, условная подстановка.

Библиотека работы с rpm

Пакет rpm-devel включает библиотеку для работы с пакетами и БД пакетов, include-файлы и документацию (8MB, сгенеренных неестественным интеллектом, так что не ожидайте от нее слишком много).

Ссылки

• официальный сайт RPM (не менялся с 1999)
• Edward C. Bailey. Maximum RPM (описывается версия RPM 3; основная часть написана во времена RH 4.0)
• RPM HOWTO (устарело и неинтересно)
• RPM Documentation Project (закрыт)