Red Hatに関する世界観３（RPM）です。
RPMのようなパッケージ管理システムを使うメリットとして、以下のようなものがある。（使うメリットというか、RPM系のディストリビューションでは必ず使わざるを得ない。）
specファイルというマクロ設定ファイルを書くことで、tarballごとに異なるソフトウェアのインストール方法やビルド方法を一本化できる。
どんなパッケージでも同じrpmコマンドでインストールや更新・削除が可能。
ソースファイルではなく、ディストリビュータの用意したバイナリパッケージからインストールできる。
一部GentooのPortageのようにソースベースのパッケージ管理システムはあるが、ほとんどのパッケージ管理システムがバイナリを主体としているため、面倒くさい作業・手間・時間の削減になる。
バイナリのRPMパッケージをビルドするために、ソースパッケージ（SRPMのこと）をリビルドできる。specファイルを書き換える場合でも簡単にリビルドすることができる。
また、SRPMを普通にインストールすればソースコードも閲覧できる。
「このパッケージは入れたけど、依存する別のパッケージもインストールしなければいけない」といった依存関係の解決。
Windowsのフリーソフトなどでは、たとえばAviUtlを入れる場合にもさまざまな別のソフトウェアをインストールしたりする必要があるが、RPMではそれらをチェックし、システムが壊れて動かないものになる危険性を減らすことができる。
また、後述するDNFを用いることで、依存パッケージを事前に計算し、自動的にコマンド一発でインストールすることもできる。
インターネットにあるリポジトリから、簡単にパッケージを最新版に更新できる。
この時、RPMの上位ツールであるDNF（昔はYumだった）を用いる。
DNFを用いることで、ディストリビューションのほとんどのパッケージ（ソースtarballなどのRPM外のパッケージを除く）を一度に更新チェック・アップデートできる。
Windows Updateと同じだが、OSだけではなくリポジトリにあるパッケージであればなんでも最新版になる。
しかしながら、最新版にする時には、システムが破壊されて動かなくならないかのチェックが必要。
DebianやUbuntuやFedoraやRHELのようなポイントリリースのディストリビューションでは、パッケージに対して深刻なバグやセキュリティ関係のアップデートしかかからないので、この心配は少ない。
Arch LinuxやGentooのようなローリングリリースのディストリビューションでは、パッケージが日々最新版にアップデートされるため危険性は高くなるが、わざわざバージョンをアップグレードしなくても日々最新版にアップデートされる。常に最新版であるため、OSの更新作業（Windows 7から10への更新作業のようなこと）が必要なく、いつでも先端の機能を追いかけられる。
逆にRPMなどでは、パッケージが既に旧来のバージョンで、最新の機能が使えないことがあるが、これはFlatpakなどで個別にサンドボックス環境にパッケージをインストールすることで、自分の好きなソフトウェアだけ最新版を入れるようなことも最近はできる。
ディストリビューションの開発が容易になる。
パッケージはspecファイルを用意するだけでSRPMやRPMをビルドできるため、specファイルの内容だけを記述すればディストリビューションは開発できる。
実際にはディストリビューションのシステムが正常に動くためのとりまとめとしての開発作業は必要だが、同じDebパッケージを使うDebianからUbuntuを分岐させるのは比較的簡単である。
その代わり、パッケージメンテナンスという仕事が必要になる。パッケージが存在していない限り、そのパッケージをユーザーは使えないため、ディストリビューションのメンテナが膨大な労力を払ってパッケージを用意・バージョンアップするメンテナンスしなければならない。
Debianなどでは、巨大なコミュニティによって、ボランティアがパッケージをメンテナンスしている。これに対してRed Hat系のディストリビューションでは、Red Hatの社員が資本力でパッケージをメンテナンスしている。その代わり、RHELは有料である。
こういうメリットはあるが、実際のところRPMパッケージが必ずしも全ソフトウェアに用意されているわけではなく、ソースパッケージからビルドすることも必要。
RPMパッケージがある場合、特に公式のディストリビュータのリポジトリにある場合は、普通はそれを使うのがベストだが、必要がなければソースtarballから解凍して手動ビルドをしても構わない。
パッケージファイル（.rpmファイル）をインストールするには以下のようにする。
rpm -ivh [パッケージファイル名]
更新するには以下のようにする。
rpm -Uvh [パッケージファイル名]
削除するには以下のようにする。
rpm -evh [パッケージ名]
また、インストール済みパッケージに含まれるファイルを表示するには以下のようにする。
rpm -ql [パッケージ名]
インストールされているパッケージの一覧を表示するには以下のようにする。
rpm -qa
「-v」は処理中のパッケージ名を、「-h」は進捗状況を表示するオプション。
以下のページが参考になります。
RPMは、ソフトウェアごとにspecファイルと言うそれぞれのパッケージの分類、依存関係、ビルド・インストールするための手順、ファイルの一覧などを事前に書いておくことで、インストールやアンインストールを分かりやすく、手軽にする仕組みです。
RPMのspecファイルはこんな感じになります：
Debパッケージの場合は以下を参照のこと：
| 要素 | 解説 |
|---|---|
| %define | マクロ宣言（何かの値や文字列を入れる変数のように使う） |
| BuildRoot | ビルドのためのルートディレクトリ |
| Summary | 説明 |
| License | ライセンス |
| Name | 名前 |
| Version | バージョン番号 |
| Release | リリース番号 |
| Source | ソースtarball |
| Prefix | インストール先のprefix |
| Group | 分類 |
| %description | 説明 |
| %prep | ソースコードtarballの解凍などの準備を行う手順 |
| %setup -q | ソースコードを解凍するためのマクロ |
| %build | ソースコードのビルドを行う手順 |
| %install | インストールの手順 |
| %files | インストールされるファイル一覧 |
| %defattr | RPMでのデフォルトのアクセス権、所有者、グループを指定 |
| %doc | ドキュメントファイルの一覧 |
（RPM を使ってソフトウェアをパッケージ化する: 第 1 回 パッケージのビルドと配布 - IBM developerWorks（Webarchive）を参考に執筆しました。）
RPMはSRPMから簡単にリビルド出来る。
必要なのはrpmbuildコマンドの導入。
まず、rpmbuildをインストールする。これはdnfから導入すればいい。
# dnf install rpm-build
直接ビルドする場合は、src.rpmに対してrpmbuildをそのまま実行すればいい（リビルドを表す--rebuildオプションを付ける）。
# rpmbuild --rebuild hoge-0.0.1-1.src.rpm
一度展開してspecファイルを修正する場合は、まずsrc.rpmをrpm -ivhコマンドでシステムにインストールし、/usr/src/redhat/SPECS/に展開されるspecファイルを編集し、specファイルに対してrpmbuildを実行する。
# rpm -ivh hoge-0.0.1-1.src.rpm # cd /usr/src/redhat/SPECS/ # vi hoge-0.0.1-1.spec # rpmbuild -bb --clean hoge-0.0.1-1.spec
rpmbuildのオプションで、バイナリパッケージだけを出力する-bbオプションがある。また、--cleanは作業中に必要なビルドツリーの後始末を行う。
RPMでは、ソースパッケージは/usr/src/redhat/SRPMS/、specファイルは/usr/src/redhat/SPECS/、x86_64のバイナリパッケージは/usr/src/redhat/RPMS/x86_64/に出来ます。ディストリビューションを開発する時は、これらのディレクトリで作業する必要があります。
SRPMからtarballを取り出す場合、単にrpmコマンドでインストールすれば良い。
$ rpm -ivh hoge-0.0.1-1.src.rpm
最近のRed Hatでは、~/rpmbuild/SOURCES/にtarballが、~/rpmbuild/SPECS/にspecファイルがインストールされる。
またバイナリRPMの場合、RPMはcpioという形式でアーカイブされているので、rpm2cpioコマンドでcpio形式に変換する。
$ rpm2cpio hoge-0.0.1-1.i386.rpm | cpio -id
作業ディレクトリに./usr/や./etc/などのディレクトリができ、その中にファイルが展開される。
/etc/rpmrcはRPMの設定ファイル。ディストリビューションやベンダーの名前（specに書くこともできる）、アーキテクチャ別のコンパイラの最適化オプションなどを設定できる。
2023.02.18編集
Fedora 31では、RPMパッケージの圧縮アルゴリズムがxzからZstdに変更される。これにより高速化や負荷軽減が期待されている。
Linuxアーカイブ・同期・デバイス処理も参照のこと。
パッケージ管理、DNF/Yum、Deb/Dpkgなどを参照のこと。
ソースからのインストールを参照のこと。
Linuxアーカイブ・同期・デバイス処理を参照のこと。
SRPMを使う場合。
Red Hat系Linuxのパッケージシステム。
Red Hat系ディストリビューションの低レベルなパッケージ管理システム。