この記事の要点

RPM (.rpm) は Red Hat / Fedora / CentOS / SUSE などで標準のパッケージ形式 内部は cpio アーカイブ + ヘッダ（Lead / Signature / Header / Payload） rpm -qpi pkg.rpm で情報、rpm -ivh で導入、依存解決込みは dnf install ./pkg.rpm .spec ファイルでビルド手順を記述、rpmbuild -ba で SRPM と RPM を生成 GPG 署名必須が運用の前提。%{vendor} の GPG キーを rpm --import しておく

要点

• RPM（.rpm）は、Red Hat 系（RHEL、Fedora、CentOS Stream、Rocky Linux、AlmaLinux、openSUSE など）で標準のバイナリパッケージ形式。
• 名称は元々 "Red Hat Package Manager" の略だったが、現在は再帰的に "RPM Package Manager" とされる。
• 内部はカスタムヘッダ + cpio アーカイブ。ビルドには spec ファイルが必要で、ソース RPM（.src.rpm）からバイナリ RPM を再現できる。
• 低レベル操作は rpm、依存解決込みの上位ツールは dnf（旧 yum）/ zypper。

概要

RPM は 1997 年に Red Hat Linux 2.0 で導入され、以降 Linux のエンタープライズ領域における事実上の標準として広く普及した。DEB と並ぶ「Linux 二大パッケージ形式」の一翼を担う存在で、特に商用ディストリ（RHEL、SLES など）のサポート対象範囲を決める根拠となっている。

DEB がテキストメタデータとシェルスクリプト中心の設計なのに対し、RPM は強くスキーマ化されたバイナリヘッダを持ち、トランザクション処理や GPG 署名検証、ファイル単位の SHA256 検証などをパッケージマネージャ側に組み込んでいる点が特徴である。

内部構造

RPM ファイルは 4 つのセクションから構成される。

• Lead — 96 バイトの固定長ヘッダ（古い RPM との互換用、現在ほぼ識別用途のみ）
• Signature — GPG 署名や SHA-256 ハッシュなど、整合性確認のためのブロック
• Header — パッケージ名・バージョン・依存・提供・スクリプトなど、すべてのメタデータが「タグ ID + 型 + 値」形式で並ぶバイナリ表現
• Payload — 実体ファイル群。cpio アーカイブを gzip / xz / zstd で圧縮したもの

ビルドの起点となる spec ファイルは、ソースをどう取得し、どうコンパイルし、どこへインストールし、どんなメタデータを付けるかを宣言的に記述する。最小例は次のような形になる。

Name:    hello
Version: 2.10
Release: 1%{?dist}
Summary: GNU Hello
License: GPLv3+
URL:     https://www.gnu.org/software/hello/
Source0: %{name}-%{version}.tar.gz
BuildRequires: gcc, make

%description
The GNU Hello program produces a familiar, friendly greeting.

%prep
%setup -q
%build
%configure
make %{?_smp_mflags}
%install
make install DESTDIR=%{buildroot}
%files
%{_bindir}/hello
%{_mandir}/man1/hello.1*

「.src.rpm」と呼ばれるソース RPM は、spec とソース tarball、パッチを一つにまとめたもので、これがあれば同一バイナリ RPM を再生成できる（再現可能ビルドの基礎）。

主な用途

• エンタープライズ Linux のパッケージ管理 — RHEL の数万 RPM が dnf を介して提供される。
• 商用ソフトの配布 — Oracle Instant Client、IBM 製品、各種商用エージェントは RPM 配布が一般的。
• ベンダーリポジトリ — EPEL、RPM Fusion、Remi、Microsoft、Docker、HashiCorp などが独自リポジトリを公開している。
• 社内パッケージ運用 — createrepo_c でメタデータを生成し、HTTP/S3 上に置けば社内 yum/dnf リポジトリになる。

関連形式との比較

• vs DEB — DEB は ar + tar、メタデータはテキスト。RPM は cpio + バイナリヘッダ、署名やトランザクションが標準。dnf 側はトランザクション履歴（dnf history）でロールバック可能。
• vs AppImage — AppImage はシステムに統合しないポータブル形式。RPM は OS と依存を共有する正攻法のインストール手段。
• vs Flatpak — Flatpak はランタイム + サンドボックス前提。RPM はシステム本体への配置で、よりカーネル/glibc 結合度が高い。
• vs MSI — どちらも宣言的なインストール定義（spec / Windows Installer データベース）を持つが、RPM は spec ファイルがテキスト、MSI は MSI データベース（実体は アーカイブに近い構造）。

コマンド・ツール

• rpm -ivh package.rpm — インストール（i=install、v=verbose、h=hash 進捗）
• rpm -Uvh package.rpm — アップグレード（既存があれば置き換え、なければインストール）
• rpm -e <name> — 削除
• rpm -qa — インストール済み一覧
• rpm -qi <name> — 詳細情報
• rpm -ql <name> — 含まれるファイル一覧
• rpm -qf /path/to/file — ファイルの所属パッケージ逆引き
• rpm -V <name> — インストール後の改変チェック（SHA256・パーミッション・所有者など）
• rpm --checksig package.rpm — GPG 署名検証
• dnf install / update / remove / history — 依存解決とトランザクション履歴管理
• rpmbuild -ba foo.spec — spec から RPM をビルド
• mock / koji — クリーンな chroot 内での公式ビルド環境

注意点

• GPG 鍵のインポートと検証を必ず行う。野良 RPM をルート権限でインストールするのは EXE の出所不明実行と同等に危険。
• ディストリビューションとメジャーバージョン依存が強い。RHEL 8 用 RPM を RHEL 7 に入れると glibc / Python のバージョン違いで動かない。
• 古い --force / --nodeps は最後の手段。依存を強引にねじ込むと rpm データベース（/var/lib/rpm）が壊れる事故が起きやすい。
• RPM データベース破損時は rpm --rebuilddb で再構築する。バックアップを取ってから実施するのが望ましい。
• ファイル名規約は <name>-<version>-<release>.<arch>.rpm。DEB がアンダースコア区切りなのに対し RPM はハイフン区切り。間違えやすい。

関連リンク

• 実行ファイル・パッケージ（親カテゴリ）
• ファイル拡張子とは（概論）
• DEB（.deb）（Debian 系の対抗形式）
• AppImage（.appimage）（Linux ポータブル配布）
• MSI（.msi）（Windows Installer パッケージ）
• DMG（.dmg）（macOS 配布イメージ）
• アーカイブ・圧縮形式（payload は cpio + xz/zstd）