パッケージ管理の基本
ソフトの導入や更新は、ディストリビューションごとのパッケージマネージャ経由で行います。Debian/Ubuntu系は apt、RHEL/MiracleLinux系は dnf を使い、インストール・更新・削除を一貫した手順で管理できます。手動でファイルを置くより依存関係を自動で解決してくれるのが利点です。
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 を中心に説明します。やりたいことは系列が違っても同じなので、片方を理解すればもう片方も類推がききます。
依存関係とリポジトリ
パッケージ管理がただファイルを置くだけの作業と一線を画すのは、依存関係を自動で解決してくれるからです。あるソフトAが動くには別のライブラリBが必要、という関係はごく普通にあり、これを依存関係と呼びます。必要なものを自分で一つずつ探して集めるのは大変な手間で、しかも取り違えれば動きません。パッケージマネージャは「Aを入れるならBも要る」と判断し、必要なものをまとめて導入してくれます。削除のときも、それに巻き込まれて不要になったものを併せて片付けられるので、システムに使われないファイルが散らかりにくくなります。
そのために、パッケージをまとめて置いてある配布元を「リポジトリ」と呼びます。既定ではディストリビューションが用意したネットワーク上のリポジトリが登録されていて、インストール時にはそこから本体と依存パッケージがまとめてダウンロードされます。必要に応じてリポジトリを追加・変更することもでき、ネットワークが使えない環境では、インストールメディア（DVDなど）をリポジトリとして指定する運用も可能です。どこから入手するかを一元管理できる点が、信頼性と保守性につながっています。
dnf の基本操作
Red Hat系では dnf がほぼすべての操作を担い、最初の引数（サブコマンド）で処理内容を切り替えます。検索は dnf list で、dnf list --installed とすればインストール済みのものを、dnf list パッケージ名 とすればそのパッケージが入手・確認できるかを調べられます。一覧は数が多いので dnf list --installed | 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 などに読み替えれば、ほぼそのまま通用します。