Convert RPM to 7Z Online (Repacking a Package Payload With LZMA2)
RPM already compresses its payload with a real algorithm — converting to 7z swaps whatever that was for LZMA2, the open-source, large-dictionary compressor behind Igor Pavlov's 1999 archiver.
- Add a file Choose or drop it here
- Pick the format Change it whenever needed
- Download the result After conversion completes
Two Compressors That Both Chase a Bigger Compression Window
RPM's Payload section is a compressed cpio archive, and the algorithm compressing it has shifted over the format's history — gzip was the long-standing default, XZ (LZMA-based) became common through the 2010s, and Fedora moved to zstd at compression level 19 starting with Fedora 31 in 2019, chosen specifically because it decompresses roughly three times faster than XZ while still beating gzip's ratio. Converting RPM to 7z means decompressing whichever of those the payload used, reading the file entries out of the cpio structure, and rebuilding them inside 7z's own container, compressed fresh with LZMA2 — the algorithm Igor Pavlov built for the archiver he first released on January 2, 1999, and distributed under the LGPL license, making both the format and the reference implementation free to use, modify, and redistribute.
LZMA2 is a refinement of the original LZMA algorithm that adds better handling of incompressible data and improved multithreading, and its dictionary can be set as large as 1.5 GB in 7-Zip's own archive-creation settings — dwarfing gzip's 32 KB DEFLATE window and giving LZMA2 a real structural advantage for finding repeated patterns across a package's many files, similar in spirit to why RPM itself eventually moved away from gzip toward algorithms with bigger windows.
That overlap is not a coincidence: XZ, one of the payload compressors RPM adopted through the 2010s, is itself a container format built around the same LZMA2 algorithm 7z uses, meaning an RPM payload already compressed with XZ and a freshly built 7z archive can end up leaning on essentially the same underlying compression math, just wrapped in different container formats — cpio-plus-XZ-headers on one side, 7z's own block structure on the other. A package still using gzip or the newer zstd default sees a bigger algorithmic change during this specific conversion than one that was already built with XZ.
7z's Solid Archiving Can Recover Some of What Splitting Into Cpio Entries Loses
Cpio, like tar, bundles files as a straightforward sequence of headers and data, and RPM's payload compressor works across that whole sequential stream rather than per file — a design that already resembles solid compression in practice. 7z's own default behavior carries that idea forward directly: 7-Zip's archive creator applies solid mode by default, treating multiple files as one continuous compression unit rather than compressing each independently the way ZIP does, so a 7z rebuilt from an RPM's payload can plausibly match or beat the original package's compression ratio on the same content, depending on which algorithm RPM originally used and at what settings.
Where 7z genuinely goes further than anything in RPM's own container is header and filename encryption: 7-Zip added AES-256 encryption support in version 4.43 (released in the mid-2000s), and its -mhe=on option encrypts the archive's header, hiding the list of filenames themselves until the correct password is entered, not just the file contents. RAR5 added an equivalent filename-hiding feature only in 2013, and RPM's own format has no comparable concept at all, since a package's file list is deliberately kept in the plainly readable Header section for tools to query without extracting anything.
What Repacking an RPM's Files as 7z Changes
- Gain — a much larger compression window: LZMA2's dictionary can reach 1.5 GB in 7-Zip's settings, letting it find matches across far more data than gzip's 32 KB window that many older RPM payloads still use.
- Gain — optional header and filename encryption: 7z's -mhe option hides the archive's file list entirely behind a password, something RPM's Header section, designed to be queryable without extraction, was never built to support.
- Lose — every install scriptlet: %pre, %post, %preun, and %postun live in the RPM Header, a section entirely separate from the Payload that 7z-building tools read from.
- Lose — the dependency graph and version metadata: what a package requires or provides exists only in the Header, invisible to any tool reading just the cpio payload.
- Lose — the GPG signature and digest verification: RPM's Signature section, used to confirm a package hasn't been tampered with, has no equivalent field in a plain 7z archive.
- Gain — a genuinely open, LGPL-licensed format: 7z's specification and reference code are both freely available, unlike RAR's proprietary internals, and the 7-Zip project itself has been open-source since its first 1999 release.
The Tools That Actually Perform This Conversion
On Linux, the manual route is rpm2cpio package.rpm | cpio -idmv to extract the files, followed by 7z a package.7z ./extracted-folder using p7zip, the command-line port of 7-Zip maintained for Unix-like systems and packaged in the repositories of most major distributions. rpm2archive, the officially distributed rpm utility, writes only to .tar.gz by default, so producing a 7z result specifically still requires the manual extract-then-repack sequence rather than a single built-in command.
On Windows, 7-Zip itself can open an .rpm file directly in its own file browser and drill straight into the embedded cpio archive without any separate tool, after which the extracted files can be rearchived as a .7z using the same application's own archive-creation dialog — a fully self-contained path that never touches a Linux command line. PeaZip offers the same RPM-browsing and 7z-writing combination on both Windows and Linux, aimed at anyone who'd rather use one graphical tool for the whole process.
Documented Complaints About Turning RPM Contents Into 7z Archives
A recurring, documented issue is older rpm2cpio and cpio builds failing to read newer RPM packages that contain files over 4 GB — RPM 4.12 and later use a stripped-down cpio variant (identified by 07070X magic bytes) for those specific packages, storing only a numeric index rather than full metadata in the cpio header, and older tools that don't recognize this format error out entirely. Updating the rpm-tools package resolves it; the source RPM isn't damaged.
A second common complaint is compression time — 7z's LZMA2 at higher compression settings is noticeably more CPU-intensive than the zstd level Fedora and other modern distributions actually ship in production, chosen specifically for its decompression speed, so repacking a large RPM payload as 7z on the same hardware that originally built the package can take visibly longer, especially with multi-gigabyte driver bundles or language runtimes.
A third pattern involves expecting the converted 7z to still carry install information — none of the dependency list, version metadata, or scriptlets exist anywhere in the cpio payload those tools read, since RPM deliberately keeps that information in the separate Header section; querying it directly from the source RPM with rpm -qpi before converting is the only way to retain it.
A fourth issue traces to numeric file ownership: RPM's cpio payload commonly stores UID/GID values tied to the original build system's account list, and when those numbers don't correspond to any real account on the machine performing the conversion, the resulting 7z can list files as owned by unfamiliar or nonexistent numeric users until ownership is reset by hand after extraction.
RPM's Payload Compression Against 7z's LZMA2
| Aspect | Original RPM | Converted 7Z |
|---|---|---|
| Container for file entries | Cpio (SVR4 or 07070X) | 7z's own header + block structure |
| Compression algorithm | Gzip, XZ, or zstd (varies by build) | LZMA2, dictionary up to 1.5 GB |
| Solid-style compression across files | Yes, inherent to the cpio stream | Yes, 7-Zip's default solid mode |
| Filename/header encryption | Not applicable; Header is plainly readable | Optional, via -mhe=on since 7-Zip 4.43 |
| Dependency metadata | Full list in Header section | Not present |
| GPG signature | Stored in Signature section | Not present |
| Installable via a package manager | Yes, on RPM-based systems | No — plain compressed files only |
Frequently Asked Questions About Converting RPM to 7Z
Will a 7z built from an RPM be smaller than the original package?
It depends on which compressor the RPM originally used. LZMA2's large dictionary often beats gzip-based payloads, but modern zstd-19 or XZ-based RPMs can be close, or occasionally smaller, depending on the specific content.
Can I encrypt the file names, not just the contents, in the converted 7z?
Yes. 7-Zip's -mhe=on option encrypts the archive header along with the file contents, hiding the file list itself until the correct password is entered — a feature RPM's own format has no equivalent for, since its file list lives in a plainly readable Header section.
Is there a one-step command from RPM straight to 7z?
Not in the standard rpm tools. rpm2archive writes only .tar.gz, so producing a 7z specifically means extracting with rpm2cpio and cpio first, then compressing the result with 7z or p7zip.
Why did my rpm2cpio command fail on a newer RPM package?
RPM 4.12 and later use a different, stripped-down cpio format for packages with files over 4 GB, and older rpm2cpio or cpio builds don't recognize its magic bytes — updating those tools resolves it.
Does the converted 7z preserve the file permissions from the RPM?
Yes, generally. Both cpio and 7z's header structure record Unix file mode bits, so ordinary read, write, and execute permissions carry through the conversion, though numeric ownership (UID/GID) may not map to real accounts on the new system.