RPM5
Содержание
История появления RPM5
Форк RPM5 был создан Джеффом Джонсоном 21 июля 2005 года (основным разработчиком RPM4 в то время), последняя совместная c RedHat версия RPM - 4.4.2 (коммит #7919). Первый релиз RPM5 - 5 января 2008 года.
Краткие сведения по истории возникновения RPM5 можно прочитать в этой статье.
Главное, что следует помнить - RPM4 и RPM5 являются независимыми параллельно развивающимися продуктами. Просто Джефф Джонсон с умом назвал свой форк.
RPM4 некоторое время пребывал в стагнации, однако после активной кампании Джеффа по продвижению RPM5, разработчики RPM4 зашевелились и тоже подобавляли всякой современной функциональности наподобие LZMA-сжатия.
Сравнительный обзор RPM4 и RPM5
| RPM 4 | RPM 5 | |
|---|---|---|
| Версия | 4.9.1.2 | 5.4.4 |
| Лицензия | GPL | LGPL |
| Опции | 73 | 182 (однако сюда вошли build-опции, а также куча опций, реализованных через alias) |
| Строки кода | 59,432 | 285,821 |
| Языки | С (90.6%) Perl (4.3%) Shell (4.3%) Others (0.8%) |
C (77.5%) Perl (14.3%) Shell (2.7%) Others (5.5%) |
| Коммиты | 7919 (до форка) + 3428 | 7919 (до форка) + 10601 |
| Релизы | 38 (до форка) + 14 | 38 (до форка) + 46 |
| Баги | 851 | 68 |
| Активные разработчики |
1 | 3 |
| Комиттеры за 2 года | Panu Matilainen (99%) Florian Festi (<1%) Ales Kozumplik (<1%) Others (<1%) |
Jeff Johnson (75%) Per Øyvind Karlsen (20%) Pinto Elia (5%) Others (<1%) |
| Пользователи | RHEL Fedora CentOS SUSE Enterprise openSUSE ALT Linux Mageia PCLinuxOS |
Mandriva Linux Unity Linux Wind River Linux CAOS Linux Ark Linux OpenPKG |
| LSB | Совместим | Несовместим - нет поддержки RPM v3 (поддержка RPM v3 - только для Mandriva Linux) |
| Сжатие | Gzip Bzip2 LZMA |
Gzip Bzip2 LZMA |
| Поддержка компиляторов |
GCC | GCC Sun Studio Intel C/C++ |
| Поддержка платформ |
Linux | Linux BSD Solaris Mac OS X Cygwin |
Мягкие зависимости
Тэги SUGGESTS и ENHANCES есть в обоих ветках RPM. Однако мягкие зависимости в RPM5 реализуются не только и не столько на основе тэга SUGGESTS, а посредством использования специального атрибута зависимостей - RPMSENSE_MISSINGOK. Если некоторая зависимость из REQUIRES имеет такой атрибут, то она считается необязательной. То, что выдает `rpm -q --suggests` (а также запросы, обращающиеся напрямую к тэгу - типа `rpm -q --qf '%{SUGGESTS}'`) - это именно записи из REQUIRES, у которых установлен флаг RPMSENSE_MISSINGOK; обращение к тэгу SUGGESTS в rpmdb обычно ничего не вернет.
В RPM4 подобной функциональности нет. Использование RPMSENSE_MISSINGOK Джефф пытался реализовать в период своих битв с RPM4 еще до форка; вроде как он его добавлял в rpm 4.4.3, который на официальном сайте отсутствует.
Комментарии
Баги и коммиты подсчитаны за все время существования проектов.
Поддержка многих платформ/компиляторов в RPM5 - это хорошо, но при выборе формата в рамках одного конкретного дистрибутива вряд ли является ключевым фактором.
Насчет поддержки LSB в RPM5 - хорошо бы иметь более детальные сведения - что именно не поддерживается. Вообще вопрос об обновлении RPM в LSB назрел давно, и мы могли бы этим заняться.
В целом, формат пакетов и функциональные возможности непосредственно инструментария rpm в обоих проектах достаточно близки - например, пресловутые Soft Dependencies (Suggests/Enhances) имеются и там, и там (добавлено Джеффом еще в RPM 4.3 в 2004 году). Большее количество опций в 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 дополнения.
| Дистрибутив | Версия | Размер патчей |
|---|---|---|
| Fedora | 4.9 | 2 Kb (0.1% от исходного кода) |
| openSUSE | 4.9 | 200 Kb (10%) |
| Mageia | 4.8 | 40 Kb (3%) |
| Ark Linux | 5.3 | 40 Kb (1%) (не считая патча, заменяющего db-5.0.21 на db-5.0.26) |
| Mandriva | 5.3 | 10 Kb (~1%) |
| ALT Linux | 4.0 | Размер diff'a - более 50% от оригинала |
(понятно, что RHEL/CentOS и клоны используют то, что отточено в Fedora, а SLES - наработки из openSUSE).
Говорить о том, что повсюду используется "чистый" RPM4 из upstream, не приходится. Размеры патчей для RPM5 в Mandriva и Ark не так уж велики по сравнению с тем, что имеет SUSE для RPM4 (не говоря уже об ALT, но это уже крайность).
Информация по RPM4 и RPM5
| RPM 4 | RPM 5 |
|---|---|
| Сайт | Сайт |
| Репозиторий | Репозиторий |
| Релизы | Релизы |
| Баги | Баги |
| Коммиты | Коммиты |
| Документация | Документация |
| API | API |
Анализ совместимости
Формат RPM-пакетов
Форматы бинарных пакетов RPM4 и RPM5 обратно и прямо совместимы, т.е. пакеты, собранные с помощью RPM4, могут быть установлены при помощи RPM5 и наоборот. Стоит заметить, что RPM5 не поддерживает RPM3, который, однако, поддерживается RPM4. Исключение составляет Mandriva, специально для которой есть поддержка RPM3 непосредственно в upstream коде RPM5. Из пресс-релиза 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-файлов - дело обычное, например, для разных Linux-дистрибутивов (из-за многочисленных downstream патчей к RPM). Некоторые изменения в формате 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, должны быть пересобраны, а некоторые - с модификацией исходного кода.
Цитаты об RPM4 и RPM5
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..
