Rocky・Fedoraでaptをdnfに置き換えるコマンド一覧

短い答え

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

以下のコマンドは、各自のサーバーで実行するためのものです。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 を使う環境です。この分岐で、ほぼ同じ系統のシステムに一方が 4 つの名前を持つ理由は、どちらを選ぶか決める前に知っておく価値があります。Red Hat Linux が Fedora、RHEL、CentOS、Rocky、AlmaLinux になった経緯では、それぞれの由来を説明しています。

パッケージ形式はツールに対応します。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 で小さなユーティリティを1つ削除すると、ライブラリが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 では、hold はプラグインではなく dpkg の状態であるため、apt-mark hold に追加の準備は必要ありません。

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

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

dnf では代わりに、リポジトリごとに 1 つのプレーンテキストファイルを /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 で使用できます。

ほとんどのベンダーはこのファイルを公開し、取得するよう案内しています。RHEL とその互換ディストリビューション向けの Docker 公式手順は、次の 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 で設定し、そこに取得を許可するリポジトリの origin を列挙します。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 は現在も実際のコマンドですか？

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

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

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

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

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

最も分かりやすい例は 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 は同じ処理を行い、用語も午後のうちに習得できます。運用期間を左右するのは、リポジトリの背後にあるリリースモデルです。Fedora は更新が速く、各リリースは公開からおよそ 13 か月後に更新提供が終了します。ワークステーションには適していますが、再構築したくないサーバーには負担になります。Rocky Linux と AlmaLinux は RHEL に追従するため、10 年間のサポート期間と、意図的に変更を抑えたパッケージバージョンを利用できます。Ubuntu は両方の形態を提供しており、サーバーにおける Ubuntu LTS と interim リリースの違いも、apt の世界で行う同じ選択です。

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

FAQ

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

実行が必要なコマンドはありません。dnf はすべてのトランザクションの前に、キャッシュ済みメタデータの経過時間を確認します。期限切れの場合は新しいコピーをダウンロードするため、dnf install は 1 か月間操作していないサーバーでも最新のパッケージを確認できます。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 に記録が残るだけです。

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

/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 がそのパッケージを、それ自体が必要とされているパッケージとして記録できるようになります。