Издаване на пакетния мениджър RPM 4.20 и начало на разработката на RPM 6

След година на разработка, пакетният мениджър RPM 4.20.0 бе пуснат. Проектът RPM4 се развива от компанията Red Hat и се използва в дистрибуции като RHEL, Fedora, SUSE, openSUSE, ALT Linux, OpenMandriva, Mageia, PCLinuxOS и Tizen. Кодът на проекта се разпространява под лицензите GPLv2 и LGPLv2.

Следващата година се очаква публикуването на значителна версия RPM 6, която ще използва нов формат на архива, позволяващ, в отличие от настоящия формат cpio, създаването на пакети с размер над 4 GB (за преодоляване на това ограничение е важно, тъй като SRC-пакетът с Chromium е близо до максимума и има размер 3.7 GB). В новата версия също така се предвижда разрешаване на използването на езика C++ за разработка на RPM. Новата значителна версия ще бъде приурочена към юбилея на проекта - на 27 ноември 2025 година ще се навършат 30 години от първия commit в RPM. Версиите RPM 5.x ще бъдат пропуснати, за да се избегнат припокривания с проекта RPM5, който не е пряко свързан с RPM на Red Hat, развиван е от независима екип от разработчици и не е обновяван от 2016 година.

Най-забележителните подобрения в RPM 4.20:

• Включена е нова утилита rpm2archive, която замества утилитата rpm2cpio и по-късно ще улесни прехода към новия формат на пакетите, който не използва cpio. За разлика от rpm2cpio, новата утилита преобразува RPM файла не в архив cpio, а в архив в формат tar, компресиран с gzip. Старата утилита rpm2cpio е заменена със символна връзка към rpm2archive.
• Предложена е декларативна система за изграждане, базирана на новата директива «BuildSystem», чрез която може да се определи системата за изграждане, използвана при формироването на пакета. Изходният код автоматично се подготвя, компилира и инсталира с оглед на определената система за изграждане, без необходимост от отделно определяне в SPEC файла на скриптове за подготовка, изграждане и инсталация в блоковете «%prep», «%build» и «%install». В RPM поддържаните системи за изграждане се определят под формата на колекции от макроси.

  Основната идея е, че декларативният формат на настройките ще позволи на разработчиците на дистрибуции да създават отделни макроси за типични процеси на компилация, за да не дефинират повтарящи се сценарии в всеки пакет. Например, вместо да определят последователности за изпълнение на командите configure и make за програми, които използват Autotools, сега е достатъчно да посочат 'BuildSystem: autotools' и да се избегнат секции '%%prep', '%%build' и '%%install'. В момента подобни макроси са подготвени за Autotools и CMake. При необходимост от внедряване на нетрадиционно поведение, на поддържащите пакетите е предоставена възможност да добавят свои макроси за пренаписване на различни етапи от изграждането на пакета.

• Добавена е поддръжка за прикрепяне на допълнителни секции с команди за подготовка, компилация, инсталация, конфигурация, почистване и проверка, допълващи основните секции %%prep, %%conf, %%build, %%install, %%check и %%clean. За стартиране на допълнителен скрипт преди изпълнението на кода от основната секция е предложена опцията '-p', а след основната секция — опция '-a'. Подобни подмени могат да се окажат полезни за точкова корекция на поведението при използване на горепосочения декларативен режим на компилиране.
• В динамично формируемите части на SPEC файловете е разрешено включването на директиви и секции, които не влияят на процеса на компилация.
• Добавен е макрос %%builddir и е реализирана управляемост чрез RPM, позволяваща свързването на собствени каталогове за компилация с отделни пакети.
• Предложен е нов протокол 'multi-file', който значително ускорява генерирането на зависимости.
• В командата rpm е добавена опцията '—json' за извеждане на резултатите от запитванията във формат JSON.
• Добавен е плъгин rpm-plugin-unshare, който осигурява изолация на скриптовете, изпълнявани в секциите за компилация, използвайки пространства на имена в Linux. Например, плъгинът позволява забрана за достъп до мрежата и ограничаване на достъпа до файловата система, както и използването на отделни частни директории /tmp и /home за защита в случай на небезопасна работа с временни файлове при компилацията на пакети.
• Предложен е публичен API за разработка на плъгини, който ще запази съвместимостта между версиите. Преди API-то за плъгини беше предназначено само за вътрешна употреба и можеше да се променя от версия на версия.
• В командата rpmkeys са добавени опции '—list' и '—delete'.
• В екипа на rpmsign е добавена поддръжка за създаване на цифрови подписи за пакети, използвайки ключове ECDSA.
• Подобрена е поддръжката на повтарящи се сборки. Добавен е макросът «%build_mtime_policy», който позволява управление на съдържанието на добавените по време на сборката етикети (чрез стойността clamp_to_source_date_epoch може да се използва фиксиран етикет, а чрез clamp_to_buildtime да се указва действителното време на сборка).
• В файловете sysusers.d е разрешено добавянето на редове за определяне на членове на групата.
• Осигурена е коректна и независима от разпределението поддръжка на файлове debuginfo.
• Обявен за остарял синтаксисът на макроси %patchN (без интервал преди N), чийто използване сега ще води до грешка (трябва да се използва синтаксисът «%patch N» или «%patch -P N», където N е номер на патча).
• Премахнат е остарял парсер OpenPGP.
• Генераторите на зависимости за Perl и Python ABI са преместени в отделни репозитории.

Източник: opennet.ru