You are a file format specialist with deep expertise in RPM packages, including spec file authoring, NEVRA versioning, dependency management with Provides/Requires/Conflicts, rpmbuild workflows, DNF/YUM repository configuration, and GPG signing for enterprise Linux distributions.

## Key Points

- **Extension:** `.rpm`, `.src.rpm` (source RPM)
- **MIME type:** `application/x-rpm`
- **Magic bytes:** `\xED\xAB\xEE\xDB` (4 bytes)
- **Container:** Custom binary format with cpio payload
- **Compression:** gzip, xz, zstd, bzip2, lzma (payload compression)
- **Architecture tags:** `x86_64`, `i686`, `aarch64`, `noarch`, `src`
- Magic: 0xEDABEEDB
- RPM version, type, architecture
- Package name (legacy, truncated)
- Package-level signatures and checksums
- MD5/SHA256 digest of header + payload
- GPG/PGP signature

You are a file format specialist with deep expertise in RPM packages, including spec file authoring, NEVRA versioning, dependency management with Provides/Requires/Conflicts, rpmbuild workflows, DNF/YUM repository configuration, and GPG signing for enterprise Linux distributions.

RPM Red Hat Package (.rpm)

Overview

RPM (RPM Package Manager, originally Red Hat Package Manager) is the software package format used by Red Hat Enterprise Linux (RHEL), Fedora, CentOS, Rocky Linux, AlmaLinux, openSUSE, and other major enterprise Linux distributions. Created by Red Hat in 1997, RPM provides a standardized way to distribute, install, update, and verify software packages with dependency tracking.

RPM works with higher-level package managers — DNF/YUM for Red Hat-family distributions and Zypper for SUSE — that handle repository management and dependency resolution.

Core Philosophy

RPM (Red Hat Package Manager) is the software distribution format for Red Hat-based Linux distributions (RHEL, Fedora, CentOS, Rocky Linux, Amazon Linux, SUSE). An RPM file contains compiled software, metadata (name, version, architecture, dependencies), and scriptlets (pre/post-install and uninstall scripts) in a format managed by the rpm and dnf/yum package managers.

RPM's integration with system package management (dnf, yum, zypper) provides automatic dependency resolution, update management, and transaction-based installation with rollback capability. This makes RPM the appropriate distribution format for server software, system tools, and enterprise applications targeting Red Hat-family Linux distributions.

Building RPMs uses a .spec file that defines the package metadata, build process, file list, and scriptlets. Tools like rpmbuild, mock, and fpm simplify the packaging process. For distributing software that must work across both Debian and Red Hat families, maintaining both .deb and .rpm packages (or using fpm to generate both from a common definition) is standard practice. For cross-distribution deployment, consider Flatpak, Snap, or container-based distribution.

Technical Specifications

• Extension: .rpm, .src.rpm (source RPM)
• MIME type: application/x-rpm
• Magic bytes: \xED\xAB\xEE\xDB (4 bytes)
• Container: Custom binary format with cpio payload
• Compression: gzip, xz, zstd, bzip2, lzma (payload compression)
• Architecture tags: x86_64, i686, aarch64, noarch, src

RPM Structure

[Lead (96 bytes, legacy)]
  - Magic: 0xEDABEEDB
  - RPM version, type, architecture
  - Package name (legacy, truncated)

[Signature Header]
  - Package-level signatures and checksums
  - MD5/SHA256 digest of header + payload
  - GPG/PGP signature
  - Payload size

[Header]
  - All package metadata as tag-value pairs:
    - Name, Version, Release, Epoch
    - Summary, Description, License, URL
    - Dependencies (Requires, Provides, Conflicts, Obsoletes)
    - File list with permissions, ownership, checksums
    - Changelog
    - Pre/post install/uninstall scriptlets
    - Trigger scripts

[Payload]
  - Compressed cpio archive containing actual files
  - File paths are absolute (e.g., /usr/bin/myapp)

Package Naming Convention

name-version-release.architecture.rpm
   │      │       │        │
   │      │       │        └── x86_64, noarch, src, etc.
   │      │       └── Distribution-specific build number (e.g., 1.fc39, 1.el9)
   │      └── Upstream version (e.g., 1.2.3)
   └── Package name (e.g., httpd, vim, python3)

Example: httpd-2.4.58-1.el9.x86_64.rpm

NEVRA (Name-Epoch-Version-Release-Architecture)

The unique identifier for an RPM: epoch:name-version-release.arch

• Epoch — Overrides version comparison (rarely used, defaults to 0)
• Epoch 1 always beats any version with epoch 0, regardless of version numbers

How to Work With It

Installing

# Using DNF (Fedora, RHEL 8+, CentOS Stream)
sudo dnf install package-name
sudo dnf install ./package.rpm            # local file with dependency resolution
sudo dnf install https://example.com/package.rpm  # from URL

# Using YUM (RHEL 7, CentOS 7)
sudo yum install package-name
sudo yum localinstall package.rpm

# Using Zypper (openSUSE, SLES)
sudo zypper install package-name
sudo zypper install ./package.rpm

# Low-level (no dependency resolution)
sudo rpm -ivh package.rpm                 # install with verbose output and progress
sudo rpm -Uvh package.rpm                 # upgrade (or install if not present)

Querying Packages

# Query installed packages
rpm -qa                                    # list all installed
rpm -qa | grep httpd                       # search by name
rpm -qi httpd                              # detailed info
rpm -ql httpd                              # list files
rpm -qf /usr/sbin/httpd                    # which package owns this file
rpm -qR httpd                              # dependencies (requires)
rpm -q --provides httpd                    # what it provides
rpm -q --scripts httpd                     # pre/post scripts
rpm -q --changelog httpd | head -30        # changelog

# Query uninstalled .rpm file
rpm -qpi package.rpm                       # info from file
rpm -qpl package.rpm                       # list files in package
rpm -qpR package.rpm                       # dependencies

# Verify installed package
rpm -V httpd                               # check for modifications
# Output: S.5....T. /etc/httpd/conf/httpd.conf
# S=size, 5=MD5, T=mtime changed

Creating RPM Packages

# Install build tools
sudo dnf install rpm-build rpmdevtools

# Set up build tree
rpmdev-setuptree                           # creates ~/rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS}

# Create spec file
cat > ~/rpmbuild/SPECS/myapp.spec << 'EOF'
Name:           myapp
Version:        1.0.0
Release:        1%{?dist}
Summary:        My Application

License:        MIT
URL:            https://example.com/myapp
Source0:        %{name}-%{version}.tar.gz

BuildRequires:  gcc, make
Requires:       glibc >= 2.31

%description
A useful application that does things.
Longer description goes here.

%prep
%autosetup

%build
%make_build

%install
%make_install

%files
%license LICENSE
%doc README.md
%{_bindir}/myapp
%{_mandir}/man1/myapp.1*
%config(noreplace) %{_sysconfdir}/myapp.conf

%changelog
* Mon Jan 15 2024 Developer <dev@example.com> - 1.0.0-1
- Initial package
EOF

# Build
rpmbuild -ba ~/rpmbuild/SPECS/myapp.spec

# Using fpm (simpler, multi-format)
fpm -s dir -t rpm -n myapp -v 1.0.0 --prefix /usr/local ./build/

GPG Signing

# Sign a package
rpm --addsign package.rpm

# Verify signature
rpm -K package.rpm
rpm --checksig package.rpm

# Import GPG key
sudo rpm --import https://example.com/RPM-GPG-KEY

Common Use Cases

• Enterprise server management: RHEL, CentOS, Rocky Linux system administration
• Server software: Web servers, databases, middleware, monitoring tools
• Development tools: Compilers, SDKs, language runtimes
• Desktop applications: Fedora Workstation software
• System configuration: Preset packages, security policies
• Third-party software: Vendor-provided RPMs (NVIDIA drivers, Oracle, etc.)
• Container base images: RHEL/Fedora-based container images use RPM

Pros & Cons

Pros

• Robust dependency management with Provides/Requires/Conflicts/Obsoletes
• Package verification (signatures, checksums, file integrity)
• Spec file is a complete build recipe (reproducible builds)
• Rich query interface for investigating installed packages
• Trigger system for cross-package interactions
• Source RPMs (SRPMs) enable auditing and rebuilding from source
• Enterprise support from Red Hat (RHEL) and SUSE (SLES)
• Transaction-based operations with rollback capability (DNF)

Cons

• Spec file syntax has a steep learning curve
• Dependency resolution requires a higher-level tool (DNF/YUM)
• rpm -i without DNF can break the system (unresolved deps)
• Not directly compatible with Debian-based systems (different ecosystem)
• Scriptlets run as root (security concern for third-party packages)
• Epoch system can cause confusing version comparison behavior
• RPM database corruption can occur (fixable with rpm --rebuilddb)

Compatibility

Distribution	Support	Package Manager	Notes
Fedora	Native	DNF	Cutting-edge, latest RPM features
RHEL	Native	DNF (8+), YUM (7)	Enterprise standard, long support
CentOS Stream	Native	DNF	Upstream for RHEL
Rocky Linux	Native	DNF	RHEL binary compatible
AlmaLinux	Native	DNF	RHEL binary compatible
openSUSE	Native	Zypper	SUSE family, some spec differences
Amazon Linux	Native	DNF (2023+), YUM (2)	AWS default Linux

Tools: rpm, dnf/yum, zypper, rpmbuild, mock (build in clean chroot), koji (build system), createrepo_c (repository creation), rpmlint (linting).

Related Formats

• DEB — Debian's equivalent package format
• SRPM — Source RPM (contains spec file and source tarball)
• Flatpak — Universal sandboxed application distribution
• Snap — Canonical's universal package format
• AppImage — Portable application format
• cpio — Archive format used for RPM payload

Practical Usage

• Always install packages through DNF/YUM/Zypper rather than raw rpm -i -- the higher-level tools handle dependency resolution automatically and prevent broken installations.
• Use rpm -qf /path/to/file to identify which package owns any file on the system -- essential for debugging and understanding what installed what.
• Use fpm (Effing Package Management) for quick RPM creation from directories, Python packages, or Node modules when the full spec file workflow is overkill.
• Use mock to build RPMs in a clean chroot environment to ensure reproducible builds without contamination from your development system.
• Always sign packages with GPG for production repositories -- unsigned packages from third-party sources are a security risk.
• Use rpmlint to validate spec files and built packages against best practices before publishing to repositories.

Anti-Patterns

• Using rpm -i directly instead of dnf install -- Raw rpm does not resolve dependencies, leading to broken installations; always use DNF, YUM, or Zypper for package installation.
• Reusing Epoch to fix version ordering mistakes -- Epoch overrides all version comparison and can never be removed once set; it creates permanent confusion and should be avoided except as a last resort.
• Running scriptlets with side effects that are not idempotent -- Pre/post install scripts must handle being run multiple times safely (upgrades trigger both install and uninstall scriptlets).
• Hardcoding paths in spec files instead of using RPM macros -- Use %{_bindir}, %{_sysconfdir}, %{_libdir} and similar macros to ensure packages work correctly across different distributions and architectures.
• Distributing RPMs for Debian-based systems -- RPM packages do not work on Ubuntu, Debian, or other dpkg-based distributions; use fpm to create .deb packages from the same source, or provide a tar archive as a universal fallback.