Fedora 46 moves to the RPM v6 package format, 25 years after v4
On October 16, 2026, Red Hat engineer Panu Matilainen filed a proposal to move Fedora 46 from the RPM v4 package format to RPM v6, a 'largely invisible' modernization that will prepare the RHEL 11 base. For administrators and third-party repository maintainers, now is the time to confirm their tooling still reads the headers.
October 16, 2026. Red Hat engineer Panu Matilainen files a change proposal to move Fedora from the RPM v4 package format to RPM v6. Twenty-five years. That is the age of the v4 format, the foundation Red Hat Enterprise Linux and Fedora have shipped on for more than two decades. RHEL 11. The next major Red Hat release, expected on a base close to Fedora 46, would inherit v6 too. Why it matters: a package-format change is rarely spectacular, but it governs signature cryptography, build tooling and the compatibility of an entire ecosystem of third-party repositories.
A face-lift designed to be invisible
The proposal, submitted to FESCo (Fedora’s Engineering Steering Committee), comes from one of RPM’s long-time maintainers. His argument fits in a single sentence: the v4 format is “a quarter century old, and this shows in things like use of obsolete cryptography, size limitations and so on.” The v6 format is described as “essentially a face-lift” that aims to “eliminate some quirks and dark corners.”
Concretely, RPM v6 brings three structural fixes. First, modern cryptographic algorithms for signatures and digests, replacing the SHA-1/MD5 era that closed with the SHAttered collision back in 2017. Second, 64-bit size tags that lift the metadata ceilings of a format designed when disks were measured in gigabytes. Third, strings always encoded in UTF-8, which removes an entire class of localization bugs.
The most instructive line is the proposal’s own admission: “many of the features already exist as extensions to the v4 format, silently used as necessary.” In other words, v6 formalizes what v4 was already doing under the table, without breaking how existing packages are read. That is why the proposal insists the change is “largely invisible to the average user”: this is about hardening the foundation, not rewriting it.
The real stakes: RHEL 11 and the third-party ecosystem
This is not just a Fedora matter. The proposal makes the link explicit: RHEL 11 is expected to be based on a state close to Fedora 46, which means RPM v6 would also become the format of the world’s most widely deployed enterprise distribution. The timeline frames it: Fedora 45 ships “in two weeks or so,” and Fedora 46 in April, after a FESCo vote the announcement already describes as unlikely to be contentious.
That is where the change, invisible to end users, becomes visible in the right places: mirrors, metadata generators such as createrepo_c, linters such as rpmlint, and above all third-party repositories — COPR, EPEL, RPM Fusion. Their packages will eventually need to be built and signed as v6 without breaking backward reading. The same RPM format is shared with openSUSE and SUSE, so what gets decided for Fedora is being watched closely by the whole RPM-based family.
A v6 package misread by an old tool means a repository that fails silently at update time. Nothing dramatic happens on day one — everything is decided upstream of the release.
For a COPR maintainer, the change is concrete: once Fedora switches its build pipeline to v6, every rebuilt package must come out in the new format while older v4 packages still install cleanly for users on Fedora 45. The format is designed so one repository can serve both generations, but only a test rebuild will tell you whether your spec files and macros survived the jump untouched.
The comparison with other ecosystems adds perspective. Debian has not changed its .deb format in decades, and Arch Linux sticks to plain, replayable compressed archives. Fedora is, among the major distributions, the one pushing the fastest modernization of its packaging chain — which is exactly why it serves as the test bed for RHEL 11. The risk, then, is not in the migration itself, widely considered smooth for standard packages, but in the long tail of tools that never get tested: a signing wrapper written ten years ago, a mirror plugin, a deployment hook that filters headers. That long tail is what the Fedora 45 release gives you time to catch up on.
Where RPM came from, and why v4 lasted a quarter century
RPM was born at Red Hat in the mid-1990s, when installing Linux software usually meant compiling from source. The v4 format itself stabilized around the year 2000. It did not survive twenty-five years out of inertia: a package format is a public contract — every tool, mirror and third-party repository parses it, and changing it means touching a foundation thousands of scripts assume is immutable.
The proposal acknowledges exactly this. v4’s limits have been known for a long time: 32-bit size tags that cap some metadata — awkward the moment a package ships an AI model or a large dataset — aging signature algorithms, and a stack of extensions (zstd compression, SHA-256 digests, Ed25519 signatures) bolted on “silently” over the years. v6 gathers those patches into a coherent format, which is precisely why the switch can stay transparent.
The migration is part of a broader modernization of the Fedora base: the distribution has already moved to dnf5, the rewrite of its package manager in C++. v6 is the next piece of the same puzzle — modernizing the foundation without ever breaking the compatibility users take for granted.
In practice, the adaptation effort concentrates on a handful of tools rather than the user: createrepo_c for repository metadata, rpmlint for validation, and any in-house script that reads query tags like %{NAME} or the headers. Those parsers are what to test first — not dnf.
What an administrator should check right now
Nothing is broken today, and that is precisely the trap: the switch is prepared before release, not after. Two checks are enough to sleep well. The first concerns signatures: rpm -K must keep validating the packages you build or sign yourself. The second concerns your reading tooling: if an in-house script parses headers with code written for v4, that script is the first thing to stress-test.
# Validate a package's signature and digests (algorithms change in v6)
rpm -K ./my-package.rpm
# Inspect a header without installing — re-test against a v6 package
rpm -qp --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n' ./my-package.rpmThe recommended path is straightforward: once Fedora 45 ships, build a test package in v6 inside a sandbox and push it through your whole chain — signing, publishing, mirroring, installing. If a link breaks, you still have months before Fedora 46 and RHEL 11 to fix it cold, without production urgency.
Verdict
The recommendation depends on where you sit in the ecosystem. If you are an end user, you have nothing to do: v6 is designed to be transparent, and dnf keeps working identically. If you maintain a third-party repository, a mirror or a tool that reads RPM, do not treat this as a formality: inventory your parsers and signing chains now, and schedule a v6 test package in the weeks after Fedora 45 lands. This is the kind of migration that is unforgiving when you discover it the day RHEL 11 is already in production. A sandboxed test package costs an afternoon today; an untested parser can cost a release next year.