rpmsign, and fixes to locking and verification behavior that matter more to package-build and fleet-management teams than to ordinary desktop users. The project published the release on August 20; Linuxiac first highlighted the installation-speed claim, while LWN.net independently reported the stable release and its wider developer-facing changes.
The headline “up to 26% faster” needs to be read as a narrow, credible optimization rather than a general promise that every DNF, YUM, or Zypper update will suddenly complete a quarter sooner. RPM’s own development record shows the gain came from replacing a repetitive file-descriptor loop with Linux’s close_range() mechanism to mark descriptors close-on-exec in one operation. It applies only on systems running Linux kernel 5.11 or later with glibc 2.34 or later, and it was measured during RPM installation work involving many scriptlets and file triggers.
That makes RPM 6.1 particularly relevant to build workers, container-image pipelines, and automated provisioning hosts where package transactions repeatedly invoke scripts. It is less likely to be conspicuous on a workstation installing a handful of packages, or on enterprise distributions whose shipped kernel, glibc, or RPM package has not yet caught up. The source release is available today; availability in a particular Fedora, RHEL, openSUSE, Mageia, or downstream repository remains a separate distribution-maintenance decision.
The performance change removes repeated descriptor work
The performance claim is rooted in a specific bottleneck rather than a broad rewrite of package installation. Before RPM 6.1, RPM’s close-on-exec setup iterated over open file descriptors and made repeated fcntl() calls. Profiling cited in the merged implementation found that work could account for about 19% of CPU time during a dnf install systemd transaction, with the routine called hundreds of times through scriptlet and file-trigger execution.
On qualifying systems, RPM 6.1 uses close_range() with the close-on-exec flag instead. The fallback remains in place for older Linux and glibc combinations, so this is a compatibility-preserving improvement rather than a new baseline requirement.
Administrators should therefore avoid treating the 26% number as a capacity-planning figure. Network download time, repository metadata refreshes, dependency solving, disk performance, package compression, SELinux labeling, scriptlets, and the transaction’s package mix can all dominate a real update. But in a controlled CI runner or image-build environment that performs many RPM transactions, reducing repeated file-descriptor handling is the sort of small systems change that can compound across a large job queue.
For Windows-based development organizations, the practical overlap is most obvious where engineers build or test RPM artifacts in WSL, Linux virtual machines, remote build farms, or Azure-hosted Linux runners. The gain is inside RPM itself, so Windows is not a target platform for the release; the benefit arrives only where those workflows actually execute a recent Linux userspace and kernel.
RPM database queries should no longer stall behind transactions
RPM 6.1 also corrects a regression introduced in RPM 6.0.0: the keystore now has its own lock instead of sharing the transaction lock. Previously, the shared locking arrangement could block all RPM database queries while a transaction was running.
This is a reliability and observability fix, not an invitation to modify package state concurrently. A package install, removal, or update remains a transaction that must preserve database consistency. What changes is that inventory and query operations should no longer be unnecessarily held up because the keystore was using the same lock.
That distinction matters for automation. Asset-management scripts, compliance collectors, support diagnostics, and package-audit tools frequently query installed RPM state while scheduled maintenance runs. A blocked query can look like a hung agent or an unavailable endpoint when the machine is simply mid-transaction. RPM 6.1 reduces that false operational coupling.
The release also repairs the RPM syslog plugin’s messages and changes its identity string to rpm, making journalctl -t rpm a more dependable way to inspect transaction history. The project says the plugin no longer reports misleading operation names or emits duplicate messages. For teams that collect journald data centrally, that should improve the signal in package-change records without requiring a new logging stack.
PKCS#11 signing is useful, but it does not remake RPM’s trust model
The most important security-oriented addition is support for signing files with PKCS#11 tokens through rpmsign. PKCS#11 is the common interface used by many hardware security keys, smart cards, HSMs, and cryptographic middleware products. In practical terms, a package-signing key can be accessed through a compatible token rather than requiring the private key to be handled as an ordinary file by the signing workflow.
The originating RPM development request described a concrete Fedora pain point: its previous process could involve sending an entire RPM to a signing server, placing private-key material in temporary memory, and relying on the RPM version installed on that signing server. The new support is intended to let rpmsign work with a PKCS#11 URI, including hardware-token scenarios such as a YubiKey-compatible setup.
The meaningful change is key handling, not automatic supply-chain security. RPM 6.1 does not make every repository package hardware-signed, rotate keys, validate a company’s signing policy, or repair a compromised build host. An organization must still configure the token middleware, determine which personnel or automation identities can invoke the key, protect PINs and token access, preserve audit records, and distribute the public verification key correctly.
The release is nevertheless a useful building block for organizations trying to avoid exportable signing keys in CI. It lets the RPM-native signing tool participate more directly in a hardware-backed process. Teams should validate their exact PKCS#11 provider, token, OpenSSL and IMA-related dependencies, and signing-server policy before replacing an existing production workflow.
RPM 6.1 also corrects excessive, misleading, or incorrect verification output in several scenarios. That sounds cosmetic, but package-verification tools are only useful when their exit status and messages consistently distinguish a real failure from noisy output. The release notes stop short of describing every affected scenario, so administrators should test their automated parsing rather than assuming message changes are harmless.
NSS lookups return, with a deliberate chroot exception
RPM 6.1 restores Name Service Switch, or NSS, user and group lookups by default. RPM 4.19.0 had disabled that behavior, but the project now allows users and groups to be supplied by the system runtime environment in addition to packages.
This affects the way package operations can resolve account and group information on systems integrated with directory-backed identity services. It can matter for installations that rely on NSS modules connected to LDAP, SSSD, Active Directory integration, or other centrally managed account sources. The feature can still be disabled using the %_passwd_path and %_group_path macros.
The critical exception is preserved: NSS lookups remain disabled unconditionally for operations using --root. That protects a common packaging and image-building boundary. A command targeting an alternate root should not silently reach into the host’s runtime identity configuration and create behavior that differs from the target filesystem’s intended state.
For image builders and distribution engineers, this is a change worth testing rather than blindly welcoming. Restoring host-aware identity lookup is useful on managed systems; reproducible build roots and installation trees need isolation. RPM’s continued --root restriction is evidence that the project recognizes those as different operational cases.
Package builders get more reproducible context and better failures
RPM 6.1 extends the macro processor with definition-time modifiers for literal and one-shot expansion, and adds -e and -g options to %define. The syntax is specialized, but its aim is familiar to spec-file maintainers: make expansion timing and scope more explicit instead of relying on subtle macro side effects.
Combining %define -e -g is equivalent to %global, according to the release notes. That gives maintainers a more direct vocabulary for whether a value should expand as it is defined and whether it should enter global context. Existing specs do not need to be rewritten merely because the options exist, but new macro behavior deserves regression testing in complex shared macro sets.
The release exports the build-script environment to rpmbuild.env under %{builddir}. Other tools can source that file to mimic the shell environment in which RPM executed build scripts. This is a practical improvement for debugging a failed %build, %install, or %check step after the fact, and for external tooling that needs to operate against the same environment rather than re-creating it imperfectly.
rpmbuild also gains k as a build-stage argument to run %check, particularly useful alongside --short-circuit. That shortens the feedback loop for developers validating tests without repeating earlier stages. Meanwhile, architecture-mismatch errors now include the affected package or subpackage plus the filenames and file types responsible, replacing an error condition that was considerably less actionable in multi-package builds.
A release policy change may outlast the individual features
RPM 6.1 is the first stable release under a revised versioning and release model inspired by the Linux kernel. The project says major versions continue to represent the RPM package format; minor releases will carry features and bug fixes without breaking behavior, and micro releases will be limited to security and bug fixes when necessary.
The project expects minor releases on a biannual or potentially quarterly rhythm, with release candidates rather than extended alpha and beta cycles. That is a significant commitment after the long-running 4.x series, where the project itself acknowledges that release semantics and the scope of minor updates became difficult for users to predict.
For downstream distributors, this may be the more consequential promise in RPM 6.1. A predictable source cadence can help plan backports, qualification, and build infrastructure updates. It does not compel conservative enterprise distributions to ship every new minor RPM version promptly, and it does not eliminate the need to test a foundational package manager before deployment.
RPM 6.1.0’s immediate value is concrete: newer build and transaction hosts can remove a measurable installation bottleneck, signing infrastructure gains a route to PKCS#11 tokens, and several long-standing operational rough edges receive focused fixes. The next practical step for administrators is to identify where RPM actually runs on Linux 5.11-plus and glibc 2.34-plus systems, then test the release in the build, signing, and inventory workflows where its changes can produce a real operational difference.