Издаване на пакетния мениджър 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, ще позволява създаването на пакети с размер над 4GB (преодоляването на това ограничение е важно, тъй като SRC-пакетът с Chromium е близък до максимума и има размер 3.7GB). В новата версия също така се планира разрешение за използване на C++ за разработка на RPM. Новата значителна версия ще бъде свързана с юбилея на проекта - на 27 ноември 2025 година ще се навършат 30 години от първия комит в 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

Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри 🔥 Купете надежден хостинг за сайтове със защита от DDoS, VPS и VDS сървъри | ProHoster