RPM5 — различия между версиями

Версия 16:45, 30 ноября 2011

Целью данного документа является сравнение двух веток развития формата RPM (Redhat Package Manager): RPM версии 4 и RPM версии 5.

История появления RPM5

Форк RPM5 был создан Джеффом Джонсоном 21 июля 2005 года (основным разработчиком RPM4 в то время), последняя совместная c RedHat версия RPM - 4.4.2 (коммит #7919). Первый релиз RPM5 - 5 января 2008 года.

Краткие сведения по истории возникновения RPM5 можно прочитать в этой статье.

Главное, что следует помнить - RPM4 и RPM5 являются независимыми параллельно развивающимися продуктами. Просто Джефф Джонсон с умом назвал свой форк.

RPM4 некоторое время пребывал в стагнации, однако после активной кампании Джеффа по продвижению RPM5, разработчики RPM4 зашевелились и тоже подобавляли всякой современной функциональности наподобие LZMA-сжатия.

Сравнительный обзор RPM4 и RPM5

Комментарии

Баги и коммиты подсчитаны за все время существования проектов.

Поддержка многих платформ/компиляторов в RPM5 - это хорошо, но при выборе формата в рамках одного конкретного дистрибутива вряд ли является ключевым фактором.

Насчет поддержки LSB в RPM5 - хорошо бы иметь более детальные сведения - что именно не поддерживается. Вообще вопрос об обновлении RPM в LSB назрел давно, и мы могли бы этим заняться.

В целом, вормат пакетов и функциональные возможности непосредственно инструментария rpm в обоих проектах достаточно близки - например, пресловутые Soft Dependencies (Suggests/Enhances) имеются и там, и там. Большее количество опций в RPM5 объясняется, в основном, алиасами - те же опции '--suggests' и '--enhances' можно элементарно получить и в RPM4.

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

Изменения в исходном коде RPM5:

• встроены abi-compliance-checker и api-sanity-autotest (~27.000 строк на Perl)
• встроен интерпретатор Lua (~27.000 строк на C)
• встроен парсер YAML (смесь на C, Shell и Ruby еще в ~30.000 строк)
• директория rpmio по сравнению с RPM4 выросла в 10 раз до 90.000 строк (втянули кучу стороннего кода - видимо, для обеспечения мультиплатформенности)
• добавили binding для Ruby и Perl

RPM в разных дистрибутивах

RPM4 используется шире, но часто в него вносятся существенные distribution-specific дополнения.

(понятно, что RHEL/CentOS и клоны используют то, что отточено в Fedora, а SLES - наработки из openSUSE).

Говорить о том, что повсюду используется "чистый" RPM4 из upstream, не приходится. Размеры патчей для RPM5 в Mandriva и Ark не так уж велики по сравнению с тем, что имеет SUSE для RPM4 (не говоря уже об ALT, но это уже крайность).

Информация по RPM4 и RPM5

Анализ совместимости

Формат RPM-пакетов

Форматы бинарных пакетов RPM4 и RPM5 обратно и прямо совместимы, т.е. пакеты, собранные с помощью RPM4, могут быть установлены при помощи RPM5 и наоборот. Стоит заметить, что RPM5 не поддерживает RPM3, который, однако, поддерживается RPM4. Из пресс-релиза RPM5:

Finally, support for the old RPMv3 (LSB) package format was removed to cleanup and simplify the code base. RPM 5, with respect to RPM format packages, now supports RPMv4 format only.

Формат spec-файлов

Форматы spec-файлов для сборки пакетов RPM4 и RPM5, в целом, не совместимы. Изменения в формате spec-файлов частично описаны в этом документе, написанном разработчиками Unity Linux при переходе на RPM5. Несмотря на то, что все старые теги поддерживаются, семантика и синтаксис некоторых из них поменялись. Изменения претерпели следующие конструкции.

Способ отключения макросов

RPM4:

#%post -n foo

RPM5:

#%%post -n foo

Т.е. чтобы закомментировать макрос надо использовать #% вместо #.

Ключевые слова в именах макросов

RPM4:

%define dirname %{version}-%{release}
...
%prep
%setup -qn %{dirname}

RPM5:

error: Bad %setup option -qn: missing argument

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

Макрос %exclude изменил значение

Макрос %exclude не влияет на список установленных файлов в секции %install. Т.е. теперь надо вручную удалять ненужные файлы в секции %install.

RPM4:

%exclude %_kde_iconsdir/hicolor/index.theme
...
%install
rm -fr %buildroot
  
%makeinstall_std -C build

RPM5:

#%%exclude %_kde_iconsdir/hicolor/index.theme
...
%install
rm -fr %buildroot

%makeinstall_std -C build
rm -f %buildroot%{_kde_iconsdir}/hicolor/index.theme

API и ABI

Согласно этой таблице, API на языке Си (библиотека librpm) претерпел серьезные изменения. ABI также изменился. Таким образом, все приложения, использующие librpm, должны быть пересобраны, а некоторые - с модификацией исходного кода.

Цитаты разработчиков Mandriva Linux

Per Øyvind Karlsen об RPM5 в mailing-листе Mandriva Maintainers:

> As far as I know, rpm4 is supported by Fedora/RedHat/CentOS and
> SUSE/OpenSUSE among the major vendors. Rpm5, on its hand, is used by
> AltLinux and Unity Linux. RPM4 is mostly stable, with long-time pending
> issues and its behavior is well-known. RPM5 is under constant
> development, with many features and without any large install base.

"long-time pending issues" is the keyword, Much of these often won't
get fixed due to ancient legacy comptibility, different prioirty of
copmany beind etc..
RPM hasn't really changed that drastically over the ten last years,
but boy are there many ways it could be improve, this is something
rpm5 focuses more on amongst other things, advancing packaging and
refactorizing away a lot of things  we really should get rid of..
As this is pretty open for people involved upstream, more fields of
iterest, different set of priorities, it makes it a lot easier for ie.
myself and others to introduce new features that will benefit them or
might just benefit others as well, either way it helps speed up
adoption of new features across distros and certainly can do good on
making it easier to create packates  with a lot less manual clumsyness
and inconsistensies..

> As you are willing to be its maintainer, I guess that now it would be a
> good time to discuss about the differences between RPM4 and RPM5, and
> why switching to RPM5 would be better for Mandriva in the long term.

It will make it a whole lot easier to maintain, all of our changes has
been reviewed and merged propery in rpm5, so no need for the pain of
regeerating 50 patches, or keep adding new ones to package where it
could've been commited upstream right away and adopted by others as
well.  There's also things like perl-RPM4 which is an obsolete,
unmaintained version of the Olivier Thauvin's perl bindings which are
part of and actively maintained at rpm5 upstream while also in use by
others, having to port the obsolete perl bindings for every new major
number of rpm is certainly not something I'd be willing to do myseslf
at least..

> Personally, I do not have a strong bias towards RPM4 and RPM5. As long
> as they work, and maintained, and we stay compatible with third-party
> RPMs out there, I am ok with any solution. But I (and I guess other
> community members too) would like to hear your points about it, as you
> certainly may have a more in-depth arguments.

There shouldn't be any compatibility issues of concern, both support
the RPMv3 (LSB) format (although rpm5 is the only rpm version  able to
produce such packages except for rpm 3.0.2 etc...) and also the RPMv4
format used by both doesn't have any incompatibilities. Also a bit
interesting feaure rpm5 actually  also
has is even support .deb packages.. ;)

... и об RPM4:

For rpm.org, I truly don't see *anything* that it provides for us, it
doesn't make us more compatible with other distros using rpm.org as
they all tend to be very heavily patched and differ from other, with
little priority in improving the situatio, which makes the whole
"rpm.org compatbility" idea as a pipe dream at best, as rpm.org
vesioned rpms shipped from various vendors tends to carry huge sets of
locally maintained patches.. For rpm 5 OTOH most patches from vendors
gets to be commited, with some of them being left to be conditioinally
able if not appropriate for everyone, this helps tracking the changes,
keeping the different practices iin a more central place for everyone
to look into and adopt..

Литература

• Linux Format, Что за штука... RPM5?
• Mandriva "Maintainers" mailing list, RPM5 switch
• Mandriva "Cooker" mailing list, RPM5 switch