Несмотря на то, что разные реализации RPM максимально совместимы между собой от версии к версии, сборщик пакетов должен иметь в виду, что RPM - развивающаяся система и разработчики добавляют функционал в каждую новую версию (кроме того, имеются форки сторонних разработчиков - прим. перев.). Когда собирается пакет, автор сборки должен принимать во внимание потенциальную аудиторию пользователей пакета. Какие версии RPM используют наши потребители? Среди этих версий необходимо выбрать "наименьший общий знаменатель" набора свойств системы, то есть использовать наиболее старую версию RPM. В качестве справочной информации, можно использовать сведения, приведенные в данной главе, касающиеся особенностей разных версий. Это руководство опирается на версию 4.1, главные же изменения в системе происходили в версиях RPM 2.5, 3.0.5, 4.0.4 и 4.1.
RPM 2.5 практически не используется, собирать под ней имеет смысл только в том случае, если пакет должен устанавливаться абсолютно из под всех версий системы.
RPM 3.0.5 - это финальный релиз серии 3.х. Этот релиз поставлялся с Red Hat 6.2. Он все еще используется некоторыми вендорами, например, Cobalt Linux.
RPM 4.0.4 использовался с выпусками Red Hat линейки 7.х, версия 4.1 - начиная с Red Hat 8.0.
RPM 2.5 поддерживает все основные функции, а также расширенные функции, такие как триггеры, интернационализация Summary:, Description:, и Group: в хэдере. Также эта версия была первой, в которой использовался формат файла RPM 3.
В RPM 2.5.3 добавлена поддержка тэга Epoch в хэдере пакета.
В RPM 2.5.4 добавлены типы %license и %readme для указания на файлы лицензии и README.
В RPM 2.5.6 включена поддержка директивы Epoch: в spec-файле. Она заменила Serial:, используя сходное поведение.
В RPM 2.5.7 была придана сила ранее введенному стандарту, касающемуся символа "-", который не должен использоваться в полях Version или Release в spec-файле.
В RPM 2.90 введена поддержка подписей и проверка пакетов с помощью технологии GPG.
В RPM 2.91 начинается использование Provides:, директивы, указывающей на абсолютные пути предоставляемых файлов. До этой версии Provides: предоставляла только списки предоставляемых возможностей без указания путей к файлам.
В RPM 3.0.2 стало возможным указывать множественные Provides:, это позволило отказаться от необходимости указывать предоставляемые возможности и имена файлов в одной строке.
RPM 3.0.3 предоставила возможность анализа зависимостей версий. До 3.0.3 в spec-файле можно было указывать зависимость от возможности или пакета, но без конкретной версии.
В RPM 3.0.4 добавлена поддержка CompressedFileNames. До этой версии RPM упаковывала абсолютные имена файлов всех архивов внутрь пакета. Хэдеры пакетов содержали определения, подобные этим:

С началом поддержки CompressedFileNames хэдеры содержат только базовые имена файлов. Теперь в хэдерах имеются определения, как показано в примере ниже, то есть для заданного каталога - номера файлов:

Каждая запись о файле теперь содержит базовое имя файла внутри заданного каталога, а также индекс номеров, каждый из которых ссылается на запись каталога. Такая технология хранения имен позволяет экономить значительное количество памяти при обработке rpm-файлов во время инсталляции.
В RPM 3.0.5 вводится поддержка компрессора bzip2. С этого момента можно использовать как архивы .tar.gz, так и архивы .tar.bz2. Несмотря на поддержку bzip2 на практике она используется сравнительно редко, так как bzip2 обладает более высокой степенью сжатия, но работает значительно медленнее и потребляет больше памяти. Кроме того, в RPM 3.0.5 начал поддерживаться формат файла RPM 4.
RPM 4.0 содержит некоторые весьма значительные изменения системы. Совершен переход на использование формата файлов RPM 4. БД RPM - вместо Berkeley db 1.85 используется Berkeley db 3.1. Изменилось имя файла БД. Изменение имени файла БД с /var/lib/rpm/packages.rpm на /var/lib/rpm/Packages позволило сосуществовать старой и новой базам вместе, если это необходимо, упрощая переход со старых релизов RPM к новым. Также была введена возможность PayloadFilesHavePrefix, эта особенность позволяет изменять путевые имена устанавливаемых файлов. С введением PayloadFilesHavePrefix все файлы в cpio-архиве имеют корневой префикс, например, ./usr/bin/ar. В этой версии RPM добавлена проверка синтаксиса spec-файла. Начиная с rpm 4.0 отпала необходимость в символьных ссылках, содержащих BuildRoot. Это сразу ликвидировало целый класс ошибок при сборке пакета. Наконец, в этой версии системы автоматически генерируются Provides: , поэтому нет необходимости заполнять эти поля в spec-файле.
В RPM 4.0.2 введено использование дайджеста SHA-1 для верификации различных областей хэдера.
RPM 4.0.3 добавляет директиву spec-файла %dev(type,major,minor), которая позволяет создавать файлы устройств в статическом варианте. Кроме того, %configure теперь поддерживает --target и host, облегчающие кросс-сборку. Директива %files дополнена субдирективой %exclude, позволяющей задать исключения из списков и шаблоны исключений. Наконец, в 4.0.3 формат файла пакета по умолчанию возвращен к версии 3, хотя версия 4 также поддерживается.
RPM 4.0.4 предоставляет поддержку PartialHardlinkSets. Иногда пакеты создаются с несколькими экземплярами одного файла, которые представлены жесткими ссылками для экономии места. До этой версии RPM обрабатывал коллекции жестких ссылок в идеологии "все-или-ничего"; или создавались все жесткие ссылки, или ни одной. Такое поведение может привести к проблемам, если некоторые ссылки относятся к файлам, помеченным атрибутами %doc или %lang. В определенных ситуациях rpm могла не установить ни одного файла, помеченного как %doc . PartialHardlinkSet исправляет эту проблему, вводя возможность создания подмножества коллекции жестких ссылок. Из интересных новшеств в RPM 4.0.4 также следует отметить возможность автоматической генерации Requires: для модулей Perl. Кроме того, с RPM 4.0.4 поддерживаются транзакции.
RPM 4.1 предоставляет подписи DSA и RSA отдельно для хэдера, что позволяет верифицировать собственно хэдер.

Итак, принимая во внимание особенности функционала RPM, необходимого в пакетах, которые вы собираете, следует иметь в виду, что некоторые особенности добавляются автоматически при сборке в зависимости от версии RPM, другие же указаны вручную в spec-файле. Например, использование директивы Requires: с конкретными версиями зависимостей возможно только начиная с версии 3.0.3. Подобно этому, релизы RPM версии 4.0 или более поздние генерируют такие rpm-пакеты, с которыми можно манипулировать лишь системами RPM, поддерживающими функционал PayloadFilesHavePrefix. В первом случае вы выбираете производство пакетов для работы с RPM версии 3.0.3 или свежее, но не с версией 2.5, во втором случае вы собираете пакеты, которые будут правильно пониматься лишь RPM версии 4.0 или более поздними.
Таким образом, наиболее верной практикой будет сборка пакетов в наиболее старой версии RPM из всех тех, которые вы собираетесь поддерживать.

Далее - Раздел 24. Формат файла rpm-пакета
Назад - Журнал изменений
Содержание