Выпуск пакетного менеджера RPM 4.20 и начало разработки RPM 6

Новости мира unix. Хотите узнать секрет вечного счастья? Откройте страницу 246.
Ответить
acolyte
Аватара пользователя
Сообщения: 3556
Зарегистрирован: 20.08.2022

#

Выпуск пакетного менеджера RPM 4.20 и начало разработки RPM 6
Дата публикации:Sat, 12 Oct 2024 11:41:35 +0300




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



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




Наиболее заметные улучшения в 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. При необходимости реализации нестандартного поведения сопровождающим пакеты предоставлена возможность подключения своих макросов для переопределения разных стадий формирования пакета.

    Добавлена поддержка прикрепления дополнительных секций c командами подготовки, сборки, установки, настройки, очистки и проверки, дополняющих базовые секции %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
Ссылка на оригинал: https://www.opennet.ru/opennews/art.shtml?num=62035

Жизнь за Нер'зула!

Ответить