RPM 6.1.0 — возврат NSS, новые макросы и более удобная работа с транзакциями

RPM 6.1.0 вышел 20 августа 2026 года как стабильное обновление пакетного менеджера RPM. Релиз возвращает NSS-поиск пользователей и групп, исправляет блокировку запросов к rpmdb во время транзакций, расширяет макропроцессор, улучшает rpmbuild, подпись через PKCS#11 и журналирование операций.

RPM 6.1.0 стал первым стабильным релизом по новой модели

Стабильный RPM 6.1.0 опубликован 20 августа 2026 года. Проект позиционирует ветку 6.1 как функциональное, но совместимое обновление серии RPM 6.x: новые возможности здесь дополняются исправлениями ошибок и регрессий, тогда как микроверсии должны использоваться прежде всего для security- и bugfix-обновлений.

Это первый стабильный выпуск, который следует новой схеме версий и циклу релизов RPM, частично вдохновлённому моделью Linux kernel. В RPM 6.x номер major по-прежнему связан с форматом пакета, minor-релизы получают новые функции без намеренного нарушения совместимости, а между ними при необходимости выпускаются микроверсии с исправлениями.

Для администраторов это означает более предсказуемый характер перехода с RPM 6.0.x на 6.1.x. Для разработчиков дистрибутивов и мейнтейнеров пакетов релиз заметнее: значительная часть изменений касается макросов, сборочного окружения, проверки подписей, NSS и поведения транзакций.

Область	RPM 6.0.x	RPM 6.1.0
Запросы к rpmdb во время транзакций	могли блокироваться из-за общего lock	хранилище ключей использует отдельную блокировку
NSS для пользователей и групп	по умолчанию отключён после изменений 4.19	снова включён по умолчанию
Макросы	обычная модель определения и раскрытия	модификаторы `l` и `o`, новые параметры `%define`
`%check` в `rpmbuild`	отдельного target-stage `k` не было	добавлен этап `k`
PKCS#11	возможности `rpmsign` были ограниченнее	добавлена подпись файлов с PKCS#11-токенами
Журнал транзакций	syslog-плагин выдавал лишние и неоднозначные записи	журнал удобнее фильтровать через `journalctl -t rpm`

Транзакции больше не должны блокировать обычные запросы к rpmdb

Одно из наиболее практичных изменений RPM 6.1.0 — переработка блокировок хранилища ключей. В RPM 6.0.0 появилась регрессия, при которой операции с key store использовали transaction lock, из-за чего запросы к базе RPM могли блокироваться на время выполняющейся транзакции.

В RPM 6.1.0 хранилище ключей получило отдельную блокировку. Это позволяет выполнять запросы к rpmdb даже тогда, когда параллельно идёт установка, обновление или удаление пакетов.

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

NSS снова используется для пользователей и групп

RPM 6.1.0 также возвращает поиск пользователей и групп через Name Service Switch по умолчанию. Такое поведение было отключено в RPM 4.19.0, но теперь RPM снова может учитывать учётные записи, доступные через системный NSS.

Это особенно актуально в корпоративных Linux-средах, где пользователи и группы могут поступать не только из локальных /etc/passwd и /etc/group, но и через LDAP, SSSD и другие источники, интегрированные с NSS.

При необходимости поведение можно изменить через макросы %_passwd_path и %_group_path. При операциях с --root NSS-поиск по-прежнему отключается безусловно, что сохраняет изоляцию при работе с альтернативным корневым каталогом.

Оптимизация закрытия файловых дескрипторов

На Linux 5.11 и новее при использовании glibc 2.34+ RPM теперь эффективнее закрывает файловые дескрипторы при выполнении scriptlet-процессов. Разработчики указывают, что в отдельных сценариях это способно сократить время установки примерно на 26%.

Эту цифру не следует воспринимать как универсальное ускорение RPM на 26%. Эффект зависит от системы и конкретной транзакции, а оптимизация относится к определённой части выполнения scriptlets. Тем не менее для массовых установок и сборочных окружений изменение может быть заметным.

Макропроцессор получил literal и one-shot определения

RPM 6.1.0 расширяет синтаксис макросов модификаторами, которые задаются непосредственно при определении. Новый формат позволяет указать <l> для literal-раскрытия и <o> для one-shot-раскрытия.

Literal-макрос не обрабатывает символ % как начало очередного RPM-макроса. Это уменьшает необходимость ручного экранирования строк, в которых процент должен остаться обычным символом.

Пример literal-определения:

%bb<l> %mymacro

В этом случае %bb раскрывается буквально в %mymacro, а не в значение, на которое указывает %mymacro.

One-shot-макрос вычисляется при первом использовании, после чего полученный результат сохраняется поверх исходного определения как literal-значение. Такой механизм удобен для дорогостоящих операций, результат которых не требуется вычислять повторно.

Пример из документации RPM:

%_python_platlib<o> %(python -c "import sysconfig; print(sysconfig.get_path('platlib'))")

Python здесь вызывается только при первом обращении к %_python_platlib; последующие обращения используют уже вычисленное значение.

%define стал точнее управлять областью и моментом раскрытия

Для %define появились параметры -e и -g.

-e раскрывает тело макроса во время определения и сохраняет получившийся результат.
-g помещает макрос в глобальный контекст; внутри параметрических макросов это позволяет явно выйти из локальной области.
сочетание %define -eg эквивалентно %global.

Для сложных spec-файлов это даёт более явное управление поведением макросов. Раньше разработчику нередко приходилось выбирать между %define и %global сразу по двум признакам — область действия и момент раскрытия. Теперь эти свойства можно задавать раздельно.

Исправлены и операции удаления макросов: rpm --undefine и Lua-функция rpm.undefine() больше не должны обходить внутренние проверки корректности.

rpmbuild стал удобнее для тестирования и внешних инструментов

RPM 6.1.0 экспортирует окружение сборочных scriptlets в файл rpmbuild.env, расположенный в %{builddir}. Это shell-совместимый файл, который сторонний инструмент может загрузить и использовать для воспроизведения окружения, близкого к тому, в котором выполняется сборка RPM.

Для разработчиков это упрощает диагностику проблем, интеграцию внешних анализаторов и ручное воспроизведение команд из %build, %install или других этапов. Раньше часть окружения приходилось восстанавливать вручную по spec-файлу и внутренним макросам RPM.

rpmbuild также получил новый target-stage k, соответствующий секции %check. Он позволяет запускать проверки как отдельный этап и особенно полезен в сочетании с --short-circuit, когда предыдущие стадии сборки уже выполнены и повторять их ради тестов не требуется.

Улучшена диагностика ошибок архитектуры. Если в пакет пытаются включить бинарники, не соответствующие заявленной архитектуре — например, ELF-файл попадает в noarch-пакет, — RPM теперь сообщает конкретный подпакет, имена проблемных файлов и их типы. Для больших spec-файлов с несколькими подпакетами это сокращает поиск причины ошибки.

Утилита rpmuncompress теперь учитывает общие параметры RPM и получила поддержку CAR-файлов. rpmuncompress и rpm-setup-autosign перенесены в стандартный $PATH; для обратной совместимости в /usr/lib/rpm сохраняются символьные ссылки.

Подпись через PKCS#11 и более понятная проверка пакетов

В RPM 6.1.0 rpmsign умеет подписывать файлы с использованием PKCS#11-токенов. Это расширяет возможности сценариев, где закрытый ключ хранится на аппаратном токене или в другом PKCS#11-совместимом хранилище и не должен экспортироваться в обычный файл на диске.

Для инфраструктуры сборки пакетов это полезно прежде всего там, где ключи подписи отделены от CI/CD-среды и доступны только через аппаратный или программный криптографический модуль.

Параллельно разработчики исправили избыточный, вводящий в заблуждение и в некоторых случаях неверный вывод при проверке подписей. rpmkeys получил обновлённую документацию по политике верификации, а в API появилась функция rpmKeyringVerifySig3(), способная возвращать дополнительные диагностические замечания.

RPM 6.1.0 не позиционируется как отдельный срочный security-only релиз: основная часть изменений относится к функциональности, корректности и исправлению регрессий. При этом стабильная версия включает исправления, прошедшие через RC-ветку и предыдущие обновления RPM 6.0.x.

Журнал транзакций проще читать через systemd journal

Плагин rpm-plugin-syslog в RPM 6.1.0 получил несколько исправлений, ориентированных на реальную эксплуатацию. Он больше не должен генерировать дублирующиеся сообщения и вводящие в заблуждение названия операций.

Идентификатор сообщений изменён с [RPM] на rpm. Благодаря этому журнал транзакций можно получать простой командой:

journalctl -t rpm

Для системного администратора это небольшое изменение, но оно делает штатный systemd journal значительно полезнее как источник истории RPM-операций. В типичном серверном окружении отпадает необходимость строить менее надёжные фильтры по тексту сообщений.

Документация и API получили отдельные улучшения

RPM 6.1.0 добавляет новые man-страницы для компонентов, которые раньше были описаны фрагментарно или зависели от устаревшего reference manual.

В релиз вошли:

elfdeps(1);
rpm-dependency-generators(7);
rpm-design(7);
rpm-scriptlets(7);
rpm-sysusers(7).

Документация rpmbuild(1) теперь подробнее описывает сам процесс сборки, а rpmkeys(8) — общую политику проверки подписей.

Изменения есть и на уровне API. Lua-scriptlets теперь учитывают rpmtsSetScriptFd(), поэтому их stdout и stderr можно перенаправлять в заданный файловый дескриптор. Добавлен Python binding rpm.ds.Ti() для получения текущего индекса trigger, а расширения тегов разрешено использовать при pattern matching в rpmdb.

Для разработчиков самого RPM также устранены ошибки и предупреждения сборки Clang. RPM 6.1.0 должен собираться этим toolchain без прежнего набора диагностических проблем; дополнительно появились готовые CMake presets.

Итоги и практический контекст

Выпуск RPM 6.1.0 не связан с изменением формата пакетов или повторением масштаба перехода на RPM 6.0. Основное улучшение касается эксплуатационных аспектов: теперь rpmdb можно запрашивать во время транзакций, поведение NSS приведено к стандартному, макросы стали более гибкими, а инструменты сборки и верификации обеспечивают больший контроль и более понятную диагностику.

Обновление особенно интересно четырём группам пользователей:

Администраторам корпоративных Linux-систем — из-за NSS и более удобной работы с транзакциями.
Мейнтейнерам RPM-пакетов — из-за новых макросов, %define -e/-g, rpmbuild.env и отдельного %check-этапа.
Инженерам сборочной инфраструктуры — из-за PKCS#11, улучшенной проверки подписей и возможности лучше воспроизводить build environment.
Разработчикам дистрибутивов и инструментов вокруг RPM — из-за изменений API, Python bindings, документации и чистой сборки Clang.

Политика новой ветки RPM 6.x предполагает, что minor-релизы не должны намеренно ломать совместимость. Это снижает риск перехода с 6.0.x, но RPM остаётся базовым системным компонентом, поэтому дистрибутивам и крупным инфраструктурам разумно прогонять собственные тесты spec-файлов, плагинов, подписей и транзакционных сценариев до массового развёртывания.

Исходный архив RPM 6.1.0 опубликован вместе с SHA256 f520810d27c74bf1c5d8b8885845c61e0c845f62d33e68b02e020633a8b62fe3. Следующим функциональным этапом в дорожной карте проекта должна стать ветка RPM 6.2, где ожидаются дальнейшие изменения в области транзакционной надёжности, воспроизводимости базы и библиотечного API.