Convert RPM to TAR.BZ2 Online (Repacking a Package Payload With Bzip2)

What Happens When an RPM Package Becomes a Bzip2-Compressed Tarball

RPM, the package format Red Hat introduced in 1997, stores its actual file contents in a Payload section that is itself a compressed cpio archive — not TAR, not ZIP, but the older cpio format, most often the SVR4 variant with a CRC checksum. The compression applied to that payload has changed across distributions and years: gzip was the long-time default, XZ (LZMA) became common through the 2010s, and Fedora switched its default to zstd at compression level 19 starting with Fedora 31 in 2019, specifically because zstd decompresses roughly three times faster than XZ while still beating the older gzip default on ratio.

Converting RPM to TAR.BZ2 means undoing whichever of those the package used, reaching the raw files inside the cpio stream, and then compressing that same file data again — this time with bzip2, the Burrows–Wheeler-transform-based algorithm that compresses data in blocks of up to 900 KB. The result carries the files themselves, wrapped in TAR's own header structure, then run through an entirely different compressor than whatever RPM originally used.

RPM's Own Payload Compression Compared With Wrapping the Result in Bzip2

There's no way to simply relabel an RPM's payload as a .tar.bz2, because the internal formats don't line up — cpio and TAR use different header layouts for each entry, and the compression envelope (gzip, XZ, or zstd) that RPM originally chose isn't bzip2 to begin with. The conversion is genuinely two decode-then-recode steps: cpio-to-TAR for the container, and whatever-RPM-used-to-bzip2 for the compression, both of which have to happen for the output to actually be a valid .tar.bz2 that any standard tool can open.

This matters practically because bzip2's own compression window tops out at 900 KB per block, smaller than the multi-megabyte or gigabyte-scale dictionaries some newer compressors use, meaning bzip2 can miss redundancy between files that are farther apart than that in the resulting tar stream — RPM payloads holding many small, similar files (like a set of documentation pages or locale files) can end up slightly larger under bzip2 than under a payload compressor with a bigger window, even though bzip2 often still beats plain gzip on the same data.

One area where bzip2 does hold up well against the original RPM payload compressor is resilience to certain kinds of file corruption: bzip2 compresses in independent 900 KB blocks, so damage to one block in a large archive doesn't necessarily prevent recovering data from the other blocks with a repair tool, whereas gzip and most single-stream compressors treat the whole file as one continuous stream where damage partway through can make everything after that point unrecoverable. That's a genuine, if narrow, reason someone might specifically want a bzip2-compressed tarball over the RPM's own payload format for long-term archival copies, even at the cost of a somewhat larger file.

What Survives the Move From RPM to TAR.BZ2 and What Doesn't

• Keep — file permissions and directory layout: TAR's header records mode bits and relative paths the same way cpio did, so the extracted structure looks the same once unpacked.
• Keep — the actual file bytes: nothing about the file contents themselves changes across a decompress-then-recompress cycle; only the compression envelope around them is different.
• Lose — every scriptlet: %pre, %post, %preun, and %postun scripts are stored in the RPM Header section, entirely separate from the Payload, so there was never a script to carry into the tarball.
• Lose — the dependency graph: which packages this one requires or provides is Header-only data, invisible to any tool that reads just the cpio payload.
• Lose — GPG signature and digest verification: the cryptographic proof of authenticity lives in RPM's Signature section and has no equivalent field in a plain TAR.BZ2.
• Trade — compression speed for ratio, or the reverse, depending on RPM's original choice: going from a zstd-compressed payload to bzip2 usually means slower compression and often a larger file for the same content, since zstd at level 19 was specifically chosen by Fedora over the alternatives for its decompression speed advantage, not to be beaten by an older algorithm.

Software That Actually Reads and Writes RPM-Derived TAR.BZ2 Files

The command-line path on any Linux system with RPM tools installed is rpm2cpio package.rpm | cpio -idmv to extract the files, followed by tar -cjf package.tar.bz2 ./extracted-folder to rebuild and compress them with bzip2 (the -j flag specifically selects bzip2 compression in GNU tar). rpm2archive, the tool distributed alongside modern rpm packages, writes directly to .tar.gz rather than .tar.bz2, so producing a bzip2 result specifically still requires the manual extract-then-recompress route rather than a single built-in command.

7-Zip on Windows opens .rpm files directly and can browse into the embedded cpio archive without any separate tool, and from there it can write out a fresh .tar.bz2 using its own archive-creation dialog once the files are extracted to a folder — a fully graphical path that never touches a Linux command line. PeaZip offers similar RPM-browsing and TAR.BZ2-creation support on both Windows and Linux, aimed at users who want a single GUI tool covering both steps of the conversion.

Documented Complaints About Repackaging RPM Contents as TAR.BZ2

A frequently reported issue is rpm2cpio producing output that cpio then refuses to parse on certain modern packages — the cause, documented in rpm.org's own release notes, is that RPM 4.12 and later uses a stripped-down cpio variant (magic bytes 07070X) for any package containing files over 4 GB, which older cpio tools simply don't recognize; the fix is updating the rpm-tools package rather than assuming the source RPM is broken.

A second common complaint is that a converted TAR.BZ2 ends up noticeably larger than expected compared with the original RPM, which traces directly back to the compression swap — a package originally built with zstd or XZ, both of which generally beat bzip2 on ratio for typical package contents, will often grow when repacked with bzip2 instead, and this is expected behavior from the algorithm change, not a sign that anything went wrong during conversion.

A third recurring problem involves numeric file ownership: RPM payloads often store the UID and GID values from whatever build system created the package, and when those numbers don't map to real accounts on the machine doing the conversion, the resulting TAR.BZ2 can list files as owned by unfamiliar or nonexistent numeric users until ownership is reset by hand.

A fourth issue reported around this conversion is compression time on large packages: bzip2 is noticeably slower to compress than zstd at the levels Fedora and other distributions actually use in production, so repacking a large RPM's payload as TAR.BZ2 on the same hardware that built the original package can take visibly longer, particularly on packages holding gigabytes of binary data such as language runtimes or driver bundles.

RPM Versus TAR.BZ2 in Concrete Numbers

Common Questions About Converting RPM to TAR.BZ2

Will a TAR.BZ2 made from an RPM be smaller than the original package?
Not necessarily. Modern RPMs often use zstd or XZ compression, both of which usually beat bzip2's ratio on typical package contents, so a bzip2-recompressed result can come out larger even though nothing was added.

Can I install the resulting TAR.BZ2 the same way I'd install the original RPM?
No. Everything a package manager needs — dependencies, version metadata, install scripts — lives in the RPM's Header section, which never makes it into a TAR.BZ2 built from just the extracted payload.

Is there a one-step command from RPM straight to TAR.BZ2?
Not built into the standard tools. rpm2archive writes .tar.gz directly, but a bzip2 result specifically requires extracting with rpm2cpio and cpio first, then compressing the result with tar's -j flag.

Why did my extracted cpio archive fail to open with an older cpio tool?
RPM 4.12 and later use a different cpio header format for packages with files over 4 GB, which older cpio and rpm2cpio builds don't recognize — updating those tools resolves the failure.

Do the file permissions from the RPM survive in the TAR.BZ2?
Yes. Both cpio and TAR headers record Unix file mode bits, so ordinary read, write, and execute permissions on the files carry through the conversion even though the container and compression both change.