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。

套件格式會隨工具而定。dnf 安裝 .rpm 檔案，其資料庫為 rpm。apt 安裝 .deb 檔案，其資料庫為 dpkg。因此，許多供應商的安裝頁面會為每個系統系列提供一個分頁；從專案發布頁面下載的 .deb 在 Rocky Linux 上也無法使用。

無論您選擇哪個系統系列，第一次登入時要做的工作都相同。新 VPS 的前十分鐘適用於兩者。只有安裝命令不同。

每個 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 這一側，apt update 是必要步驟，因為 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 安裝額外項目，因為套件保留狀態是 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 套件。EPEL 是目前最接近通用 PPA 的選項，許多教學都預設已啟用 EPEL。如果 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 套件都依賴其中的元件，因此只啟用 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 只能重新安裝啟用的軟體庫中仍存在的套件版本。因此，舊版建置從鏡像站移除後，復原會因找不到套件而失敗。回復操作也只會處理到套件資料庫。升級改寫的設定檔仍會維持改寫後的內容，服務首次啟動時執行的資料庫結構描述遷移也不會回復。dnf 會還原檔案，但不會還原資料。

apt 沒有對等功能。/var/log/apt/history.log 會確實記錄發生的事情，包括命令列，但讀取日誌不等於復原操作。使用 apt 時，必須手動處理：執行 apt list -a nginx 查看套件庫仍保留哪些版本，再執行 sudo apt install nginx=<exact version string> 鎖定其中一個版本，並加入 sudo apt-mark hold nginx，避免下一次升級撤銷你的修正。

套件群組沒有 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 最接近的概念是中繼套件，也就是內容幾乎為空、唯一內容是相依性清單的套件，例如 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 都能正常運作。有一個習慣值得改掉：yum-config-manager 在 dnf 4 系統上仍以獨立 binary 的形式存在，但目前文件使用的寫法是 dnf config-manager；系統移轉至 dnf 5 後，這個寫法仍可繼續使用。

dnf 4 與 dnf 5：複製指令前先確認

dnf 5 是重新改寫的版本，數個指令的拼寫也有所變更。Fedora 41 及後續版本以 dnf 提供此版本。企業版重建發行版切換的速度較慢，因此不要只依發行版名稱猜測。請在自己的伺服器上執行 dnf --version，並查看第一行輸出，因為該版本號碼決定下方應使用哪種語法。

Docker 提供了最清楚的示範，會針對兩個版本分別發布不同的 repository 指令。在 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 旗標，並顯示使用方式錯誤，而不是新增 repository。另一個常見差異是啟用 repository：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 的對應方式是將 .repo 檔案放在 /etc/yum.repos.d/ 中，該檔案包含名稱、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 升級導致伺服器故障，可以復原嗎？

可以，但有條件。執行 sudo dnf history 找出交易編號，再執行 sudo dnf history info <id> 確認實際變更內容，最後執行 sudo dnf history undo <id>。如果任何已啟用的 repository 都不再提供舊版套件，復原就會失敗，因為 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，因此舊版教學大多仍可運作。新的 script 和文件應使用 dnf，因為 yum 名稱僅用於相容性；此外，應優先使用 dnf config-manager，不要使用較舊的 yum-config-manager binary。

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

因為 dnf 會在同一筆交易中移除其他套件都不再需要的相依套件；apt remove 則會保留這些套件，直到你另外執行 apt autoremove。因此，在 Ubuntu 上看似很小的移除操作，在 Rocky Linux 上可能會列出很長的清單。這份清單通常是正確的，但確認前仍應仔細檢查。如果清單中有你想保留的套件，請先明確安裝該套件，讓 dnf 將它記錄為使用者明確需要的套件。