22.3. Notable changes to RPM

A new OpenPGP backend based on Sequoia

RPM now uses Sequoia PGP for the verification of package signatures, which replaces the legacy OpenPGP parser. Sequoia PGP is a modern, Rust-based implementation of the OpenPGP standard that focuses on safety and robustness.

Major updates to cryptography

RHEL 10.1 introduces the following updates to RPM cryptography, which provide major security enhancements to signing and verifying RPM packages:

rpmsign --addsign no longer replaces existing signatures in an RPM package

Before this update the rpmsign --addsign command replaced any existing signatures in an RPM package. Starting from RHEL 10.1, rpmsign --addsign only adds new signatures and never deletes any. If an identical signature is already present in a package, RPM prints an error message and keeps the existing signature untouched.

A new rpmlua command-line tool

This tool runs the RPM Lua interpreter in a standalone way that you can use for the development and testing of Lua scriptlets and macros. For more information, see the rpmlua(8) man page on your system.

A new rpmsort command-line tool

This tool allows you to sort RPM versions passed on standard input, similar to sort(1) but with the awareness of RPM versioning scheme. For more information, see the rpmsort(8) man page on your system.

A new dbus-announce plug-in

This plug-in writes basic information about RPM transactions to the system D-Bus, for example, when packages are installed or removed. Other programs can subscribe to these signals to be notified of such events.

Downgrade support in --freshen mode

Previously, you could use the --freshen option only to upgrade packages that were already installed and skip packages that were not installed. With this enhancement, you can also use this operation to downgrade such packages. To do this, combine the --freshen (F) option with the --oldpackage option.

Support for dynamic spec generation

You can now add subpackages during the build process by placing files containing spec parts into a predefined location. For more information, see Dynamic Spec Generation.

A new --shell option in the rpmspec command-line tool

This option runs an interactive RPM macro interpreter that you can use for the development and testing of RPM macros, either in or outside of the context of a spec file. For more information, see the rpmspec(8) man page on your system.

Support for applying individual patches in %autopatch

You can now list specific patch numbers as positional arguments, for example, %autopatch 1 4 6 to apply patch numbers 1, 4 and 6.

Proper shell-like globbing and escaping in the %files section

Wildcard patterns and escaping characters, such as backslashes and quotes, in filenames are now interpreted in a more conventional way, mirroring the behavior of shell interpreters such as Bash. Previously, undocumented limitations and exceptions to these rules could have unexpected results and could prevent the use of more complex patterns in the %files section of a spec file.

A new tag in source RPM packages containing the parsed and expanded contents of the spec file

To help with analyzing packaging issues, a new RPMTAG_SPEC tag is now added to source RPM packages. This tag includes the contents of the expanded spec file in the form used during the build. You can view this tag by executing the rpm --qf ‘%{spec}’ -q /path/to/my/src.rpm command.

Build parallelism now considers system resources

RPM now considers the available physical memory and address space when estimating the number of parallel processes and threads to use when building packages. This helps to prevent performance issues or build failures on systems with constrained resources, such as systems with a large number of CPUs but a limited amount of memory.

Payload compression with zstd now supports multi-threading

The zstdio compression method now accepts an optional T parameter that specifies the number of threads to use when compressing payload during the build. This can help reduce the build time of large packages. To enable this feature, set the %_binary_payload and %_source_payload macros accordingly. For more information, see the associated comment block in the /usr/lib/rpm/macros file and the expected format table.

A new optional %conf spec file section

You can use this section to configure the unpacked sources for building instead of configuring them in the %prep or %build sections of a spec file.

Lua-native macro integration

The embedded Lua interpreter has been updated to include the following enhancements:

New macros for convenient string operations implemented in Lua

You can now perform basic string operations, such as extracting a substring or obtaining the length, directly by using RPM macros, without having to execute shell subprocesses. For more information, see String operations.

Unified calling conventions for built-in and user-defined macros

The %foo arg, %{foo arg}, and %{foo:arg} notations used for calling macros are now equivalent. Note, however, that there might still be minor exceptions and differences.

Multiple new built-in macros

Multiple new built-in macros are now available, most notably:

New %preuntrans and %postuntrans scriptlets

The %preuntrans and %postuntrans uninstall-time scriptlets complement the existing install-time %pretrans and %posttrans scriptlets:

Support for signing packages with Sequoia PGP is available as a Technology Preview

The macros.rpmsign-sequoia macro file that configures RPM to use Sequoia PGP instead of GnuPG for signing packages is now available as a Technology Preview. To enable its usage, perform the following steps:

User and group name resolution is now strictly local

When installing packages, RPM now obtains the information about users and groups from the passwd(5) and group(5) files on the local system, respectively, as opposed to using the Name Service Switch (NSS).

The build tree (%_builddir) is now removed by default after a successful build

Previously, rpmbuild(8) only cleaned up the build directory in the --rebuild mode, not in the more commonly used modes, such as -bb. Consequently, multiple packages being built caused the unnecessary accumulation of files over time. With this enhancement, if you prefer to always keep the build tree, for example, to investigate a non-fatal build issue, you can use the --noclean option.

The %patch directive must now explicitly specify the patch numbers to apply

You can specify the patch number either of the following ways: