パッケージ管理の基本
ソフトの導入や更新は、ディストリビューションごとのパッケージマネージャ経由で行います。Debian/Ubuntu系は apt、RHEL/MiracleLinux系は dnf を使い、インストール・更新・削除を一貫した手順で管理できます。手動でファイルを置くより依存関係を自動で解決してくれるのが利点です。
ここまではOSに最初から備わったコマンドを使ってきた。だが、必要なソフトがまだ入っていなかったら、それを導入する仕組みが要る。それがパッケージ管理だ。
インターネットから実行ファイルを拾ってきて手で置けばいい、と思うかもしれないが、それには落とし穴がある。
Linuxはあくまで土台となるOSであり、その上で実際の仕事をするのは個々のソフトウェアだ。これらの導入・更新・削除を一手に引き受けてくれる仕組みがパッケージ管理で、その中心となるソフトをパッケージマネージャと呼ぶ。
手で置くだけでは足りないのは、1つのソフトを動かすには、実行プログラム本体だけでなく、設定ファイル・ライブラリ・マニュアルなど多数のファイルが必要になるからだ。
それらをひとまとめにした単位が「パッケージ」で、パッケージマネージャはこのまとまりを単位として、ソフトウェアを安全に出し入れする。
野良の実行ファイルを手で置く方法に比べ、どこから来た何が入っているかが明確で、更新も削除もきれいに行えるのが大きな利点だ。
🐧 環境によって使うコマンドが違う
ここで一つ、初学者が混乱しがちな事実に触れておく。パッケージ管理は、Linuxの「系列（ディストリビューション）」ごとの違いが最もはっきり出る部分なのだ。
大きく分けて2つの系統がある。Debian/Ubuntu系はパッケージファイルの拡張子が .deb で、apt や dpkg といったコマンドを使う。
一方、RHEL（Red Hat Enterprise Linux）やMiracleLinuxが属するRed Hat系は拡張子が .rpm で、dnf（旧来の yum の後継）や rpm を使う。
rpm ファイルの名前には決まりがある。たとえば gcc-8.4.1-1.el8.x86_64.rpm は「パッケージ名(gcc)・バージョン(8.4.1)・リリース(1.el8)・対応アーキテクチャ(x86_64)」を表す。
このトラックで前提とするMiracleLinuxはRed Hat系なので、ここではおもに dnf を中心に説明する。やりたいことは系列が違っても同じなので、片方を理解すればもう片方も類推がきく。
🧩 1つ入れるだけで済まない理由
パッケージ管理がただファイルを置くだけの作業と一線を画す、最大の理由がある。依存関係を自動で解決してくれるのだ。
あるソフトAが動くには別のライブラリBが必要、という関係はごく普通にあり、これを依存関係と呼ぶ。
必要なものを自分で一つずつ探して集めるのは大変な手間で、しかも取り違えれば動かない。パッケージマネージャは「Aを入れるならBも要る」と判断し、必要なものをまとめて導入してくれる。
削除のときも、それに巻き込まれて不要になったものを併せて片付けられるので、システムに使われないファイルが散らかりにくくなる。
その依存パッケージは、リポジトリと呼ばれる配布元から来る。リポジトリとは、パッケージをまとめて置いてある場所のことだ。
既定ではディストリビューションが用意したネットワーク上のリポジトリが登録されていて、インストール時にはそこから本体と依存パッケージがまとめてダウンロードされる。
必要に応じてリポジトリを追加・変更することもできる。ネットワークが使えない環境では、インストールメディア（DVDなど）をリポジトリとして指定する運用も可能だ。
どこから入手するかを一元管理できる点が、信頼性と保守性につながっている。
⚙ dnf の使い分け
理屈が分かったら、実際のコマンドに触れよう。Red Hat系では dnf がほぼすべての操作を担い、最初の引数（サブコマンド）で処理内容を切り替える。
検索は dnf list で、dnf list --installed とすればインストール済みのものを、dnf list パッケージ名 とすればそのパッケージが入手・確認できるかを調べられる。
一覧は数が多いので dnf list --installed | less のようにパイプで less に渡すと読みやすい（前に覚えた less がここでも効く）。
導入は dnf install パッケージ名、更新は dnf upgrade パッケージ名、削除は dnf remove パッケージ名 だ。
たとえば dnf install gcc とすれば、Cコンパイラを含む gcc 本体に加え、それが依存する cpp や glibc-devel、kernel-headers などもまとめて導入され、「全部で7パッケージを入れます」のように内訳が示される。
ソフトを入れるだけで管理者権限を求められるのは、インストール・更新・削除がシステム全体に影響するからだ。実際には sudo dnf install パッケージ名 のように sudo を付けて実行する。
実行時には依存関係を解決したうえで「これらをインストールします。よろしいですか? [y/N]」と確認が出るので、内容を見て y で承認する。
問い合わせに自動で答えてスクリプト化したいときは -y オプションを付けるが、何が入るかを把握しないまま -y を多用するのは避け、慣れるまでは内訳を一度目で確かめる癖をつけると安全だ。
検索で目当てのものが「一致するパッケージはありません」と出れば、それは未インストール（または名前違い）を意味する。
↩ 更新で壊れたら元に戻せる
更新は便利だが、「更新したらアプリが動かなくなった」ときが不安になる。だが安心していい。dnf は過去の操作をトランザクションとして記録している。
dnf history で履歴を一覧でき、dnf history undo 番号 で特定の操作をまるごと取り消せる。直前の状態へ戻せるので、本番サーバでは更新前に履歴番号を控えておくと安心だ。
なお、RHEL系では内部処理を高速化した後継の dnf5 への移行が進んでいるが、基本的な使い方はこれまでと変わらない。
ここまでを振り返ると、手動で個別のファイルをコピーして導入する方法に比べ、パッケージ管理は依存関係の解決・一貫した更新・きれいな削除・操作履歴という利点をまとめて提供するのが分かる。
さらに、配布元が署名したパッケージを使うことで、改ざんされていない正規のソフトを入れられるという安全面の意味もある。
だからこそ、ソフトを入れたくなったらいきなり外部サイトのインストーラを探すのではなく、まず公式リポジトリにパッケージがないかを dnf list や dnf search で確かめる。この順番を癖にしておくと、システムを長く安全に保てる。
Debian/Ubuntu系を触るときは、同じ発想で apt install などに読み替えれば、ほぼそのまま通用する。