Convert RPM to TAR Online (Getting the Files Out of a Red Hat Package)

What an RPM Package Actually Contains Before Any Conversion Happens

An RPM file, the package format created in 1997 by Erik Troan and Marc Ewing at Red Hat, is built from four sections written one after another: a 96-byte Lead that identifies the file by its magic bytes (mostly legacy today, since everything it holds is duplicated in later sections), a Signature section carrying a GPG signature and digest values used to verify the package hasn't been tampered with, a Header holding every piece of package metadata — name, version, dependencies, the full file list, and install scriptlets — and finally the Payload, which is where the actual files live.

That Payload is not some RPM-specific format. It's a cpio archive, historically using the SVR4 cpio variant with a CRC checksum, then compressed — first with gzip by default, later with bzip2 or LZMA/XZ on many distributions, and since Fedora 31 (2019) with zstd at compression level 19, chosen specifically because it decompresses roughly three times faster than XZ while still compressing tighter than the older default. Converting RPM to TAR means reaching past the Lead, Signature, and Header, decompressing that payload, and re-bundling the same file data using TAR's own header format instead of cpio's.

Why RPM's Payload Is Already a TAR-Like Format Underneath

Cpio and TAR solve the same basic problem — bundling multiple files with their names and metadata into one stream — using different header layouts, and both originate from the same Unix backup-and-tape era. Since cpio is already just a sequence of file entries with headers, going from RPM to TAR is really two smaller conversions stacked together: first strip the RPM wrapper to reach the cpio payload, then re-encode each entry's header fields (name, size, mode, mtime) into TAR's format instead of cpio's, which is exactly what the officially distributed rpm2archive tool does in one pass, writing a .tar.gz directly from an RPM's payload without a separate manual cpio step.

The older, more manual route is rpm2cpio piped into cpio -idmv, which extracts the files to disk rather than repackaging them — going from there to an actual TAR file means running tar over the extracted directory afterward as a separate step. Since version 4.12, RPM also uses a stripped-down cpio variant (magic bytes 07070X) for any package containing files larger than 4 GB, where the cpio header stores only an index number pointing back into the RPM's own Header for the real filename and metadata — a detail that has caused documented compatibility problems with older rpm2cpio builds that don't recognize the newer magic bytes.

What Converting RPM to TAR Keeps and What It Drops

• Keep — the actual file contents and Unix permissions: TAR's header, like cpio's, records file mode bits, so ordinary executable/read/write permissions on the files themselves survive the move.
• Keep — directory structure: the file paths embedded in the cpio payload carry straight over into TAR entries with the same relative layout.
• Lose — every install scriptlet: %pre, %post, %preun, %postun, and trigger scripts live in the RPM Header section, not the Payload, so a TAR built from just the payload never had them to begin with.
• Lose — dependency and version metadata: package name, version, release, architecture, and the full list of required or provided packages exist only in the Header, invisible to anything reading just the extracted files.
• Lose — the GPG signature and digests: the cryptographic proof that a package came from a trusted source and wasn't altered lives in the Signature section, which a TAR of the payload never carries forward.
• Lose — RPM's own compression choice: whatever the payload used internally (gzip, XZ, or zstd) gets decompressed during conversion; a plain TAR that follows is uncompressed unless a compression step is added afterward.

Where RPM-to-TAR Conversion Actually Works Today

rpm2archive ships as part of the standard rpm package tools on Fedora, RHEL, and openSUSE, and is purpose-built to hand off RPM contents to systems that have no RPM tooling at all — the man page for it describes exactly this use case. rpm2cpio is even more widely available, present on essentially every RPM-based distribution as well as in some Debian and Arch repositories for cross-distribution work, but it stops at cpio, requiring a separate cpio extraction and then a fresh tar invocation to actually produce a TAR file.

On Windows, 7-Zip can open an .rpm file directly in its file browser and drill down into the embedded cpio archive without any command-line tool, and the older Altap Salamander file manager ships a dedicated RPM viewer/extractor plugin for the same purpose — both let a Windows user reach the payload's files without ever touching rpm2cpio. Neither of these graphical Windows tools writes a proper Header-derived TAR by itself; they extract the files directly, so producing an actual .tar afterward still means archiving the extracted folder with a separate tool.

On Debian-based systems, the older alien utility takes the conversion a step further by reading the RPM Header's dependency fields and translating what it can into a .deb package, or, with its --to-tgz option, into a compressed tarball directly — useful specifically when the target system has neither RPM nor a way to run rpm2archive, though alien has always been described by its own author as producing packages of "questionable" reliability compared with a properly rebuilt native package.

Real Problems People Hit Converting RPM Packages to Plain Archives

A documented, recurring complaint involves rpm2cpio producing a cpio stream that the cpio command then refuses to read correctly on certain newer RPM packages — traced to the RPM 4.12+ stripped-down cpio format used for packages containing files over 4 GB, which some older rpm2cpio and cpio builds simply don't recognize. The fix in practice is updating to a current rpm-tools package rather than treating the RPM itself as corrupted.

A second common point of confusion is expecting a converted TAR file to still carry the package's version number, dependency list, or install scripts — none of which exist anywhere inside the cpio payload those tools read, since RPM deliberately keeps that information in the separate Header section. Anyone who needs the metadata alongside the files has to query it directly from the original RPM with a command like rpm -qpi or rpm -qlp before or instead of converting, since a TAR built from the payload alone has no way to recover it afterward.

A third practical issue shows up around ownership: RPM's cpio payload commonly records numeric UID/GID values tied to the build system's account list, and when those numeric IDs don't match any real account on the machine doing the conversion, the extracted-then-retarred files can end up owned by unexpected or nonexistent users unless ownership is explicitly reset during the process.

RPM and TAR Measured Side by Side

Questions About Turning an RPM Package Into a TAR File

Does converting an RPM to TAR let me install it like a package again?
No. A TAR is just a bundle of the raw files with no dependency tracking, no scriptlets, and no version metadata — none of what a package manager needs to actually install and track it as a package.

Why does my rpm2cpio command fail on some RPM files but not others?
Newer RPM versions (4.12 and later) use a different, stripped-down cpio format for packages containing files over 4 GB, and some older rpm2cpio and cpio builds don't recognize that variant's magic bytes — updating the tools usually resolves it.

Will the install scripts still run if I extract an RPM's files into a TAR?
No. Scriptlets like %post live in the RPM Header, a separate section from the Payload that TAR conversion tools read — there's no install script to run because it was never part of the file data being converted.

Is there a single command that goes straight from RPM to TAR?
Yes — rpm2archive writes a .tar.gz directly from an RPM's payload in one step, which is faster than the older two-step approach of extracting with rpm2cpio and cpio and then running tar separately.

Can I get the RPM's file ownership to match my current system after converting?
Not automatically. The payload commonly stores numeric UID/GID values from the original build system, which may not correspond to real accounts elsewhere — ownership often needs to be reset manually after extraction.