RPM Package MIME Type

What does application/x-rpm mean?

The application/x-rpm media type identifies an RPM Package Manager package, normally stored with the .rpm extension. An RPM can be a binary package ready for installation or a source package containing source material and build instructions. Both use the same extension and outer format.¹

An RPM package combines files with structured metadata such as its name, version, target architecture, dependencies, file ownership, and installation scripts. RPM is a core package technology in Fedora, Red Hat Enterprise Linux, openSUSE, SUSE Linux Enterprise, and several other operating systems.²

application/x-rpm is a widely used conventional label, not an IANA-registered media type. It does not appear in IANA's application registry. The x- prefix reflects older practice for unregistered subtypes.³

Some systems also use application/x-redhat-package-manager. The freedesktop.org shared MIME database treats that value as an alias of application/x-rpm, not as a different package version.⁴

How do you identify an RPM file?

An RPM package begins with the four bytes ED AB EE DB. This magic value starts the package lead and is the strongest quick identifier for the format.⁶

Do not rely only on the extension. A file named update.rpm may still be incomplete or unrelated data. Likewise, the magic bytes identify the container but do not establish that its metadata is valid, its payload is safe, or its signature belongs to a trusted publisher.

The classic RPM layout has four logical sections:¹

RPM v4 normally uses a CPIO payload, with Gzip as the historical default and support for other compressors. RPM v6 modernizes the format with stronger cryptography, 64-bit sizes, independently verifiable payload hashes, and a streamlined RPM-specific payload derived from CPIO.¹⁷

The first four bytes remain the same across these generations. A MIME detector therefore cannot determine all compatibility details from the magic number alone. Use RPM's own library or command-line tools to parse the header.

Where did RPM come from?

Marc Ewing and Erik Troan developed the first RPM after Red Hat's experience with earlier RPP, PMS, and PM package systems. Version 1 was written in Perl, while RPM 2.0, released in March 1996, was the first version entirely in C.⁵⁸

The current source tree dates to 1995. The official timeline records RPM 1.2 in September 1995 and the first C-tree commit in November of that year.⁵ RPM later became part of the Linux Standard Base packaging specification, although that standard covered the older v3 package format.⁵

RPM now describes both a file format and the low-level package-management system that builds, queries, verifies, installs, updates, and removes packages. Higher-level tools such as DNF add repository handling and dependency resolution around RPM transactions.²⁹

How do you inspect or open an RPM package?

Web browsers do not render RPM package contents. They normally download the response for a package manager or inspection tool.

On an RPM-based Linux system, query an unfamiliar package before installing it:

rpm -qip package.rpm
rpm -qlp package.rpm
rpm --checksig package.rpm

The first command displays package information, the second lists its files, and the third checks available signatures and digests. These operations inspect the package without installing its payload. RPM's query mode accepts package files, while its verification facilities cover package and file metadata.¹⁰

When installation is appropriate, DNF5 can install a local package and resolve dependencies from configured repositories:

dnf5 install ./package.rpm

The DNF5 documentation explicitly supports local RPM paths and resolves the transaction's dependencies.⁹ This is usually safer and more convenient than invoking a low-level install command for a standalone package.

Support in Poly

Poly recognizes .rpm filenames and the exact application/x-rpm value as its RPM archive type. It can store, sync, share, version, download, and find the outer file by name and ordinary file properties. Poly's MIME mapping does not include the application/x-redhat-package-manager alias, so an upload identified only by that value may fall back to a generic type.

Poly treats the package body as opaque:

• It does not parse the RPM header, dependency declarations, file list, or scriptlets.
• It does not validate signatures or extract the payload.
• It does not generate a thumbnail or package-content preview.
• It does not index files packed inside the RPM.
• The Poly agent cannot read or reason about the package contents.

Download the package and use RPM or DNF when you need to inspect or install it. Poly's recognition of the MIME type is file classification, not a statement that the package is valid, compatible, or trustworthy.

Security and package authenticity

RPM packages may contain executable programs and scriptlets that run during installation or removal. Installing one can modify system files and services with administrator privileges. Treat an RPM as software, not as a passive compressed document.

RPM supports cryptographic digests and OpenPGP signatures. Modern format versions provide stronger header and payload digests, but a successful cryptographic check only proves integrity and association with a particular key. You must still decide whether that key belongs to a publisher you trust.⁷¹¹

Extracting instead of installing reduces some risk, but it is not the same as making the content harmless. A payload can contain pathnames, symlinks, executable files, permissions, and other metadata that deserve review. Extract into a new directory as an unprivileged user, never over the live filesystem.

RPM packages, source RPMs, and Debian packages

The filename often provides a useful hint, but the package header is authoritative:

A source RPM is not simply the uncompressed source code for a binary package. It is packaging input, commonly including the upstream source archive, distribution patches, and a spec file that tells rpmbuild how to produce packages.

Converting between RPM and Debian formats is not a lossless rename. Their dependency models, lifecycle scripts, filesystem policies, architecture names, and distribution integration differ. Even if a conversion tool repacks the files, the result may not behave correctly on the target distribution. Obtain a package built for your exact distribution and release whenever possible.