Rocky 與 Fedora 的 apt、dnf 指令對照

簡短說明

從 apt 改用 dnf，主要是術語不同。apt install nginx 變成 dnf install nginx。apt remove nginx 變成 dnf remove nginx。apt update 沒有直接對應項目，因為快取副本過期時，dnf 會自行重新整理套件庫中繼資料。簡單的對照只需一個畫面。真正有用的部分，是 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 上移除一個小型工具時，可能會顯示要一併移除十幾個函式庫。確認前請先閱讀清單。

重新整理中繼資料、檢查等待中的更新，以及執行升級。

# 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 update 在 apt 端是必要的，因為 apt 會使用磁碟上的現有中繼資料，也可能安裝數個月前就已離開套件庫的版本。dnf 會在每次交易前檢查快取的新舊程度，並自行下載最新中繼資料，因此 sudo dnf makecache 只用於強制立即下載，而不是等到下次安裝時才下載。

apt 將整個系統升級分成兩種情況，而 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，也沒有個人套件封存庫（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 及其重建版本提供的指示只需執行兩個命令：

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

第一行是必要的，因為 config-manager 是 plugin，不是 dnf 本身的一部分。略過這一行，第二行就會因為 No such command: config-manager 而失敗。你也可以手動使用 curl，將相同的 .repo 檔案下載至 /etc/yum.repos.d/；結果完全相同。在 VPS 上安裝 Docker 說明 Debian 端的相同步驟；其中相應步驟會將來源清單與 signing key 寫入兩個不同的目錄。

版面配置的差異會決定軟體庫發生問題時應從哪裡查找。apt 將定義放在 /etc/apt/sources.list 和 /etc/apt/sources.list.d/，並將 signing key 分開存放在 /etc/apt/keyrings/ 下。dnf 則將所有內容放在 /etc/yum.repos.d/，而 key 是 .repo 檔案中的 URL，因此只需讀取一個檔案，也只需刪除一個檔案。較新的 apt 已透過 deb822 格式朝相同結構發展，每個軟體庫使用一個 .sources 檔案。如果你曾遇到 Ubuntu 上的 deb822 重複來源錯誤，就已經接觸過這個問題在 apt 端的情況。

EPEL 是多數指南預設已啟用的套件庫

Extra Packages for Enterprise Linux (EPEL) 是 Fedora 專案，負責為 RHEL 及其重建版本建置 Fedora 套件。它是目前最接近通用 PPA 的方案，而且有大量教學預設系統已啟用它。如果 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 時，啟用 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 使用者改用 dnf 後最常缺少的功能。

這項功能確實有許多限制，依賴它之前應先了解。undo 只能重新安裝仍存在於已啟用儲存庫中的套件版本。因此，舊版套件一旦從鏡像站移除，復原就會因找不到套件而失敗。復原也只會處理到套件資料庫。升級時被改寫的設定檔仍會維持改寫後的內容，服務首次啟動時遷移的資料庫 schema 也仍會維持遷移後的狀態。dnf 會還原檔案，但不會還原資料。

apt 沒有對等功能。/var/log/apt/history.log 會準確記錄發生的事情，包括命令列，但讀取日誌不等於復原變更。apt 的復原方式必須手動處理：先執行 apt list -a nginx，確認 archive 仍保留哪些版本，再執行 sudo apt install nginx=<exact version string> 固定其中一個版本，並加入 sudo apt-mark hold nginx，避免下一次升級再次覆寫你的修正。

Package groups 沒有 apt 的對應功能

dnf 可以使用單一指令安裝一組具名套件。

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

較舊的指南會寫成 dnf groupinstall "Development Tools"。這個別名可在 dnf 4 中運作，但已在 dnf 5 移除，因此兩個字的 dnf group install 是各版本都能使用的唯一寫法。請使用這個寫法即可。

apt 沒有套件群組。Debian 最接近的概念是中繼套件（metapackage），這是一個內容基本上為空、只包含相依性清單的套件，例如 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。此篩選功能依賴套件庫發布安全性勘誤，因此請先使用 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 都能正常運作。有一個習慣值得改掉：在 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 旗標，會顯示用法錯誤，而不是新增套件庫。另一個常見操作是啟用套件庫：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 release 在伺服器上的差異，就是在 apt 生態系中做出相同的選擇。

截至 2026 年 8 月，這些都是常見的 VPS 映像檔。先選擇你需要的支援週期，再學習上面的 10 個指令。

FAQ

dnf 對應 apt update 的指令是什麼？

不需要執行任何指令。dnf 會在每次交易前檢查快取中繼資料的新舊程度，過期時下載最新副本。因此，即使伺服器已經一個月未操作，執行 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 的對應方式是將名稱、baseurl 和 gpgkey 放在 /etc/yum.repos.d/ 內的 .repo 檔案中。供應商會替你發布這個檔案；在 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 升級導致伺服器故障，可以復原嗎？

可以，但有條件。執行 sudo dnf history 找出交易編號，再用 sudo dnf history info <id> 查看確切變更內容，最後執行 sudo dnf history undo <id>。如果較舊的套件版本已不在任何已啟用的儲存庫中，復原就會失敗，因為 dnf 沒有可重新安裝的來源。這項操作也只能反轉套件變更。升級改寫的設定檔，或服務首次啟動時執行資料庫遷移所造成的變更，都會維持原狀。apt 完全沒有對應指令，只有 /var/log/apt/history.log 中的紀錄。

yum 在 Rocky Linux 和 AlmaLinux 上仍可運作嗎？

可以，因為 /usr/bin/yum 是指向 dnf 的 symbolic link。請在自己的主機上使用 ls -l /usr/bin/yum 確認。輸入 yum install httpd 實際上會執行 dnf，因此舊教學大多仍可運作。撰寫新腳本和文件時，請使用 dnf；yum 這個名稱僅用於相容性。也請優先使用 dnf config-manager，不要使用較舊的 yum-config-manager binary。

為什麼 dnf remove 想刪除這麼多套件？

因為 dnf 會在同一筆交易中移除其他套件都不需要的相依套件，而 apt remove 會保留這些套件，直到你另外執行 apt autoremove。因此，在 Ubuntu 上看似只移除少量套件的操作，在 Rocky Linux 上可能會列出很長的清單。這份清單通常是正確的，但確認前仍應先閱讀。如果清單中有你想保留的套件，請先明確安裝該套件，讓 dnf 將其記錄為獨立指定要保留的套件。