Rocky・Fedoraでaptをdnfに置き換える方法

短い答え

apt から dnf への移行は、ほとんどが用語の変更です。apt install nginx は dnf install nginx になります。apt remove nginx は dnf remove nginx になります。apt update に直接対応するものはありません。dnf は、キャッシュされたリポジトリメタデータが古くなると自動的に更新するためです。簡単な対応表は 1 画面で確認できます。本当に役立つのは、直接対応しない 4 つの操作です。リポジトリの追加、トランザクションの取り消し、パッケージグループのインストール、 unattended updates の実行です。

以下の各コマンドは、ご自身のサーバーで実行する前提です。y に答える前に、dnf が表示するトランザクションの概要を確認してください。特にパッケージを削除する場合は、必ず確認します。

dnf を使用するディストリビューションと apt を使用するディストリビューション

dnf は Fedora、Red Hat Enterprise Linux (RHEL)、および RHEL の再構築版である Rocky Linux、AlmaLinux、CentOS Stream のパッケージマネージャーです。apt は Debian と、Debian から派生したすべてのディストリビューションのパッケージマネージャーです。VPS では、ほぼ常に Ubuntu を指します。これ以外の選択肢はありません。プロバイダーのイメージ一覧に Rocky Linux または AlmaLinux がある場合は、dnf を使用します。Ubuntu がある場合は、apt を使用します。

パッケージ形式はツールに対応します。dnf は .rpm ファイルをインストールし、データベースは rpm です。apt は .deb ファイルをインストールし、データベースは dpkg です。そのため、多くのベンダーのインストールページには各系統用のタブがあり、プロジェクトのリリースページからダウンロードした .deb は Rocky Linux では使えません。

どちらの系統を選んでも、最初のログインで行う作業は同じです。新しい VPS で最初の 10 分に行う作業は、どちらにも適用できます。変わるのはインストールコマンドだけです。

apt コマンドと dnf の対応コマンド

インストール、削除、検索、表示を行います。どちらもほぼ同じ語を使います。

# apt
sudo apt install nginx
sudo apt remove nginx
apt search nginx
apt show nginx

# dnf
sudo dnf install nginx
sudo dnf remove nginx
dnf search nginx
dnf info nginx

apt show は dnf info です。このグループで名前が変わる動詞はこれだけですが、動作には注意が必要な違いがあります。dnf remove は、ほかで必要とされていない依存関係も削除します。一方、apt remove は、後で apt autoremove するために依存関係を残します。そのため、Rocky Linux で小さなユーティリティーを削除すると、12 個のライブラリも削除する提案が表示されることがあります。確認する前に一覧を確認してください。

メタデータを更新し、保留中の更新を確認して、アップグレードします。

# apt
sudo apt update
apt list --upgradable
sudo apt install --only-upgrade nginx
sudo apt upgrade

# dnf
sudo dnf makecache
dnf check-update
sudo dnf upgrade nginx
sudo dnf upgrade

apt では apt update が必須です。apt はディスク上のメタデータをそのまま使用するため、数か月前にアーカイブから外れたバージョンでもインストールしてしまいます。dnf は各トランザクションの前にキャッシュの経過時間を確認し、必要であれば新しいメタデータを自動的にダウンロードします。そのため sudo dnf makecache は、次回のインストール時ではなく、今すぐダウンロードさせる場合にだけ使用します。

apt はシステム全体のアップグレードを 2 つに分けますが、dnf は分けません。apt upgrade はインストール済みパッケージを削除しないため、更新の際に削除が必要になると処理を停止します。apt full-upgrade は削除を許可するバージョンです。dnf にはこの制限がありません。したがって、dnf upgrade に対応するのは apt full-upgrade であり、apt upgrade ではありません。dnf update は同じコマンドの古い別名で、現在も使用できます。

スクリプトで使用する場合は、次の点が重要です。dnf check-update は、更新が保留中の場合に終了ステータス 100、ない場合に 0 を返します。apt list --upgradable はどちらの場合も 0 を返すため、スクリプトで出力を解析する必要があります。

インストール済みのパッケージを一覧表示し、ファイルを所有しているパッケージを確認します。

# apt
dpkg -l
dpkg -S /usr/sbin/nginx
dpkg -L nginx
apt-file search /usr/sbin/nginx

# dnf
dnf list --installed
rpm -qf /usr/sbin/nginx
rpm -ql nginx
dnf provides /usr/sbin/nginx

各ブロックの最後の行は、その前の行とは異なる質問に答えます。dpkg -S と rpm -qf はインストール済みのパッケージだけを検索するため、「このファイルを配置したパッケージは何か」という質問に答えます。apt-file search と dnf provides はリポジトリを検索するため、「このファイルを取得するには何をインストールすればよいか」という質問に答えます。apt-file は Ubuntu では別のパッケージであり、初回実行前に sudo apt-file update が必要です。dnf provides には追加の操作は必要ありません。ただし、回答のために dnf がリポジトリのファイル一覧をダウンロードするため、初回実行には時間がかかることがあります。

まだインストールしていないパッケージの内部ファイルを一覧表示するには、dnf repoquery -l nginx を使用します。apt では apt-file list nginx に相当します。

自動削除、キャッシュの消去、バージョンの固定を行います。

# apt
sudo apt autoremove
sudo apt clean
sudo apt-mark hold nginx
apt-mark showhold
sudo apt-mark unhold nginx

# dnf
sudo dnf autoremove
sudo dnf clean all
sudo dnf versionlock add nginx
dnf versionlock list
sudo dnf versionlock delete nginx

versionlock は Rocky Linux または AlmaLinux にデフォルトでインストールされていません。そのため、新規環境では最初の行が No such command: versionlock で失敗します。まず sudo dnf install python3-dnf-plugin-versionlock でインストールしてください。apt の apt-mark hold には追加の操作は必要ありません。hold はプラグインではなく dpkg の状態だからです。

マッピングが崩れる箇所: リポジトリの追加

ここで Ubuntu 管理者は、存在しないコマンドを探すことになります。dnf に add-apt-repository はなく、Personal Package Archive (PPA) もありません。PPA は Launchpad が提供するサービスであり、Launchpad は Ubuntu のインフラストラクチャです。RPM の世界には、これに相当するものはありません。

dnf では代わりに、/etc/yum.repos.d/ にリポジトリごとのプレーンテキストファイルを配置します。ファイル名の末尾は .repo です。

[docker-ce-stable]
name=Docker CE Stable
baseurl=https://download.docker.com/linux/centos/$releasever/$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg

$releasever と $basearch は dnf の変数です。dnf は実行時にメジャーリリース番号と CPU アーキテクチャを代入します。そのため、同じファイルを version 9 と version 10、x86_64 と aarch64 で使用できます。

多くのベンダーはこのファイルを公開し、取得するよう案内しています。Docker の RHEL とその再構築版向けの手順は、次の 2 つのコマンドです。

sudo dnf -y install dnf-plugins-core
sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

1 行目が必要なのは、config-manager が dnf 自体の一部ではなく、プラグインだからです。これを省略すると、2 行目は No such command: config-manager で失敗します。同じ .repo ファイルを curl でダウンロードし、手動で /etc/yum.repos.d/ に配置しても問題ありません。結果は同じです。VPS への Docker のインストールでは、同じ作業の Debian 側について説明しています。Debian では、同等の手順により、ソースリストと署名キーを 2 つの異なるディレクトリに書き込みます。

レイアウトの違いによって、リポジトリに問題があるときに確認する場所も変わります。apt は定義を /etc/apt/sources.list と /etc/apt/sources.list.d/ に保持し、署名キーを /etc/apt/keyrings/ 以下に分けて保管します。dnf はすべてを /etc/yum.repos.d/ に保持し、キーは .repo ファイル内の URL として指定します。そのため、確認するファイルも削除するファイルも 1 つです。新しい apt では、deb822 形式により、リポジトリごとに 1 つの .sources ファイルを置く同じ構成へ移行しています。Ubuntu での deb822 の重複ソースエラーに遭遇したことがあるなら、この問題における apt 側の事情はすでに経験済みです。

EPEL は多くのガイドが前提とするアーカイブです

Extra Packages for Enterprise Linux (EPEL) は、RHEL とそのリビルド向けに Fedora パッケージをビルドする Fedora プロジェクトです。この環境における汎用 PPA に最も近い存在であり、多くのチュートリアルが有効化済みであることを前提としています。プロジェクトの公式 Web サイトで確認できるパッケージについて dnf install が No match for argument と回答する場合、最初に確認すべきなのは EPEL です。

Rocky Linux と AlmaLinux では、次のように実行します。

sudo dnf config-manager --set-enabled crb
sudo dnf install epel-release
sudo dnf makecache

CRB は CodeReady Builder の略で、ディストリビューションに含まれているものの、デフォルトでは有効化されていないライブラリのリポジトリです。ほとんどの EPEL パッケージは CRB 内の何らかのパッケージに依存します。そのため、CRB を有効化せずに EPEL を追加しても、追加時点では失敗しません。後でインストールするときに、存在を知らなかったパッケージへの未解決の依存関係として失敗します。先に CRB を有効化すれば、この種のエラーは発生しなくなります。

RHEL 自体では、CRB は config-manager 経由ではなくサブスクリプションを通じて提供されます。この手順では Red Hat 公式の EPEL 手順に従ってください。Fedora では、メインリポジトリに EPEL がバックポートするパッケージがすでに含まれているため、これらの設定は必要ありません。EPEL の方針では、RHEL が提供するパッケージを置き換えません。そのため、リポジトリを追加しても、サーバーにすでにインストールされているものは変わりません。

dnf history undo、apt にはない機能

dnf はすべてのトランザクションを記録し、その逆の処理を構成できます。

sudo dnf history
sudo dnf history info 42
sudo dnf history undo 42

dnf history は、各トランザクションを開始したコマンドラインとともに、トランザクションの番号付き一覧を表示します。undo は反対のトランザクションを構成します。そのトランザクションでインストールされたパッケージは削除され、アップグレードされたパッケージは元のバージョンに戻ります。これは、apt から移行したユーザーが最も必要とする機能です。

ただし、実際には制限があります。利用する前に把握しておく必要があります。undo が再インストールできるのは、有効なリポジトリにまだ存在するパッケージバージョンだけです。そのため、古いビルドがミラーから削除されると、not-found エラーで undo に失敗します。ロールバックの対象もパッケージデータベースまでです。アップグレードによって書き換えられた設定ファイルは、そのまま書き換えられた状態です。サービスが初回起動時に移行したデータベーススキーマも、移行済みのままです。dnf はファイルを元に戻します。データは元に戻しません。

apt に相当する機能はありません。/var/log/apt/history.log はコマンドラインを含め、実行された内容を正確に記録します。ただし、ログを読むことは処理を取り消すことではありません。apt 側での復旧は手動です。まず apt list -a nginx を実行して、アーカイブに残っているバージョンを確認します。次に sudo apt install nginx=<exact version string> で 1 つのバージョンを固定し、sudo apt-mark hold nginx を追加して、次回のアップグレードで修正が取り消されないようにします。

パッケージグループに相当する apt の機能はありません

dnf では、名前付きのパッケージセットを 1 つのコマンドでインストールできます。

dnf group list
dnf group info "Development Tools"
sudo dnf group install "Development Tools"

古いガイドでは dnf groupinstall "Development Tools" と記載されています。このエイリアスは dnf 4 では機能しますが、dnf 5 では削除されています。そのため、どの環境でも使える表記は 2 語の dnf group install だけです。これを使えば、以後この違いを気にする必要はありません。

apt にはグループがありません。Debian で最も近い仕組みはメタパッケージです。これは通常、build-essential のように依存関係の一覧だけを内容とする空のパッケージです。実際の違いは削除時に現れます。メタパッケージを削除しても、apt autoremove を実行するまで依存パッケージはインストールされたままです。一方、dnf group remove を実行すると、そのグループのパッケージも同じトランザクションで削除されます。

unattended-upgrades と dnf-automatic

どちらの系列にも、ログインしているユーザーがいなくても更新をインストールする仕組みがあります。ただし、共有しているのは目的だけです。

Ubuntu と Debian では、パッケージは unattended-upgrades です。設定ファイルは /etc/apt/apt.conf.d/50unattended-upgrades で、そこに更新元として許可するリポジトリを指定します。Ubuntu で unattended-upgrades を設定するでは、この設定ファイルと、それに伴う再起動の扱いを説明しています。

Rocky Linux、AlmaLinux、Fedora では、パッケージは dnf-automatic です。有効にする systemd timer によって動作が決まります。

sudo dnf install dnf-automatic
sudo systemctl enable --now dnf-automatic-install.timer
systemctl list-timers 'dnf-automatic*'

dnf-automatic-install.timer は更新をダウンロードして適用します。dnf-automatic-download.timer は更新をダウンロードするだけで停止し、インストールはユーザーに任せます。dnf-automatic-notifyonly.timer は報告だけを行います。これらの unit はそれぞれ /etc/dnf/automatic.conf にある apply_updates の設定を上書きするため、設定ファイルの内容よりも選択する timer のほうが重要です。

セキュリティ修正だけに限定するには、/etc/dnf/automatic.conf で upgrade_type = security を設定します。このフィルターは、リポジトリがセキュリティ errata を公開していることを前提とします。そのため、まず dnf updateinfo list security で確認してください。更新が保留されているシステムで結果が空になる場合、メタデータが存在しません。その場合、security は何もインストールしません。

Fedora では、dnf 5 により unit 名が変更されました。新しい名前は dnf5-automatic.timer で、同じ /etc/dnf/automatic.conf を読み込みます。

yum は現在も実際のコマンドですか？

はい。ただし、yum 自体は何も実行しません。Rocky Linux、AlmaLinux、CentOS Stream では、/usr/bin/yum は dnf を指すシンボリックリンクです。次のコマンドで確認できます。

ls -l /usr/bin/yum
dnf --version

古い yum 構文がチュートリアルに登場し続けるのは、その大部分が現在もそのまま通用するためです。yum install、yum remove、yum update はすべて使用できます。ただし、1 つ改めるべき習慣があります。yum-config-manager は dnf 4 のシステムでは独立したバイナリとして現在も存在しますが、dnf config-manager は現在のドキュメントで使われている表記です。また、システムが dnf 5 に移行しても使い続けられます。

dnf 4 と dnf 5: コマンドをコピーする前に確認する

dnf 5 は書き直されており、複数のコマンドの表記が変更されています。Fedora 41 以降では、dnf として提供されています。エンタープライズ系の再構築版では切り替えが遅れているため、ディストリビューション名だけで判断しないでください。自分のサーバーで dnf --version を実行し、1 行目を確認してください。その番号によって、以下のどの構文を使うかが決まります。

最も分かりやすい例は Docker です。Docker は、それぞれに異なるリポジトリコマンドを公開しています。RHEL とその再構築版で dnf 4 を使用する場合:

sudo dnf config-manager --add-repo https://download.docker.com/linux/rhel/docker-ce.repo

Fedora で dnf 5 を使用する場合:

sudo dnf config-manager addrepo --from-repofile https://download.docker.com/linux/fedora/docker-ce.repo

同じベンダーで、目的も同じですが、表記は異なります。dnf 5 では config-manager がサブコマンド中心のツールに変更されたため、旧式の --add-repo フラグは受け付けられません。その結果、リポジトリは追加されず、使用方法のエラーが表示されます。もう1つ遭遇する変更は、リポジトリの有効化です。dnf 4 の dnf config-manager --set-enabled crb は、dnf 5 では dnf config-manager setopt crb.enabled=1 になります。

実際に重要な選択

パッケージマネージャーだけを基準にサーバーのディストリビューションを選ぶのは、判断軸として適切ではありません。dnf と apt は同じ処理を行い、用語も午後のうちに覚えられます。1 年の運用を左右するのは、リポジトリの背後にあるリリースモデルです。Fedora は更新が速く、各リリースは公開からおよそ 13 か月後に更新の提供が終了します。これはワークステーションには適していますが、再構築したくないサーバーでは運用上の負担になります。Rocky Linux と AlmaLinux は RHEL に追従するため、10 年間のサポート期間があり、パッケージバージョンも意図的に大きく変わりません。Ubuntu には両方の方式があり、サーバーにおける Ubuntu LTS と中間リリースの違いは、apt の環境で同じ判断を行うものです。

2026 年 8 月時点では、これらはすべて一般的な VPS イメージです。必要なサポート期間を選び、その後で上記の 10 個のコマンドを覚えてください。

FAQ

apt update に相当する dnf のコマンドは何ですか？

実行が必要なコマンドはありません。dnf は各トランザクションの前にキャッシュ済みメタデータの古さを確認し、期限切れであれば新しいコピーをダウンロードします。そのため、1 か月間操作していないサーバーで dnf install を実行しても、現在のパッケージが使用されます。sudo dnf makecache も存在し、このダウンロードを強制できますが、実際の用途は、次回のインストール時に発生する待ち時間を、任意の時刻に移すことです。「何が保留されているか」を確認するコマンドは dnf check-update です。これは apt list --upgradable に対応し、更新がある場合はステータス 100 で終了します。

Rocky Linux または Fedora に PPA に相当するものはありますか？

ありません。Personal Package Archive は Launchpad のサービスであり、Launchpad は Ubuntu のインフラストラクチャです。そのため、add-apt-repository に翻訳対象となるものはありません。RPM に相当するものは、/etc/yum.repos.d/ に置かれる .repo ファイルです。このファイルには、名前、baseurl、gpgkey が記載されています。ベンダーがこのファイルを公開し、dnf 4 では sudo dnf config-manager --add-repo <url>、dnf 5 では sudo dnf config-manager addrepo --from-repofile <url> によって適切な場所へダウンロードします。追加の汎用ソフトウェアには、通常 EPEL を使用します。sudo dnf config-manager --set-enabled crb を実行し、続けて sudo dnf install epel-release を実行して有効化します。

サーバーを壊した dnf upgrade を元に戻せますか？

制限付きで可能です。sudo dnf history を実行してトランザクション番号を確認し、sudo dnf history info <id> で変更内容を正確に確認してから、sudo dnf history undo <id> を実行します。有効なリポジトリのいずれにも以前のパッケージバージョンが存在しない場合、再インストールする対象がないため、取り消しは失敗します。また、元に戻るのはパッケージの変更だけです。アップグレードによって書き換えられた設定ファイルや、サービスの初回起動時に移行されたデータベースは、そのまま残ります。apt には同等のコマンドがなく、/var/log/apt/history.log に記録が残るだけです。

yum は Rocky Linux と AlmaLinux でまだ動作しますか？

/usr/bin/yum が dnf へのシンボリックリンクであるため、動作します。ls -l /usr/bin/yum で実際の環境を確認してください。yum install httpd と入力すると dnf が実行されるため、古いチュートリアルの多くは現在も機能します。新しいスクリプトやドキュメントでは dnf を使用してください。yum という名前は互換性のためだけに残されているためです。また、古い yum-config-manager バイナリより dnf config-manager を優先してください。

dnf remove はなぜこれほど多くのパッケージを削除しようとするのですか？

dnf は同じトランザクションの一部として、ほかのパッケージが必要としない依存関係を削除するためです。一方、apt remove は apt autoremove を別途実行するまで、それらをインストールされたままにします。そのため、Ubuntu では小規模に見える削除操作でも、Rocky Linux では長い一覧が表示されることがあります。通常、この一覧は正しいですが、確定する前に確認してください。一覧に残したいパッケージがある場合は、先に明示的にインストールしてください。dnf がそのパッケージを独立して必要なものとして記録できるようにするためです。