Rocky、AlmaLinux 和 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

Fedora、Red Hat Enterprise Linux (RHEL) 以及 RHEL 的重建发行版 Rocky Linux、AlmaLinux 和 CentOS Stream 使用 dnf 作为包管理器。Debian 及其衍生发行版使用 apt。在 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

Rocky Linux 或 AlmaLinux 默认不会安装 versionlock，因此在全新系统上，第一行命令会因 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 架构，因此同一个文件可用于版本 9 和版本 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 是一个插件，并不属于 dnf 本身。如果跳过这一行，第二行会因 No such command: config-manager 而失败。您也可以手动使用 curl 将同一个 .repo 文件下载到 /etc/yum.repos.d/，结果完全相同。在 VPS 上安装 Docker介绍了 Debian 中同一任务的处理方式；对应步骤会将源列表和签名密钥分别写入两个不同的目录。

目录布局的差异决定了软件仓库出现问题时应从哪里查找。apt 将定义文件保存在 /etc/apt/sources.list 和 /etc/apt/sources.list.d/ 中，并将签名密钥单独存放在 /etc/apt/keyrings/ 下。dnf 将所有内容保存在 /etc/yum.repos.d/ 中，密钥则作为 URL 写在 .repo 文件中，因此只需读取一个文件，也只需删除一个文件。较新的 apt 正通过 deb822 格式逐步采用相同的结构，即每个软件仓库使用一个 .sources 文件。如果您遇到过 Ubuntu 上的 deb822 重复源错误，就已经接触过这个问题在 apt 中的对应部分。

EPEL 是大多数教程默认使用的软件仓库

Enterprise Linux 的 Extra Packages（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 用户切换后最常用、也最想念的功能。

此功能确实存在限制，依赖它之前应先了解这些限制。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 会在同一事务中一并删除该组中的软件包。

无人值守升级和 dnf-automatic

这两类工具都支持在没有用户登录时安装更新。它们除了用途相同外，没有其他共同点。

在 Ubuntu 和 Debian 上，软件包是 unattended-upgrades，配置文件为 /etc/apt/apt.conf.d/50unattended-upgrades。您可以在其中列出允许拉取更新的软件源。在 Ubuntu 上配置无人值守升级介绍了该配置文件，以及由此引出的重启问题。

在 Rocky Linux、AlmaLinux 和 Fedora 上，软件包是 dnf-automatic。您启用的 systemd 定时器决定其行为。

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只报告可用更新。这些单元都会覆盖 /etc/dnf/automatic.conf 中的 apply_updates 设置，因此，您选择的定时器比配置文件中的设置更重要。

要将其限制为仅安装安全更新，请在 /etc/dnf/automatic.conf 中设置 upgrade_type = security。该过滤器依赖软件源发布安全勘误，因此请先使用 dnf updateinfo list security 检查。如果系统有待安装的更新，但结果为空，说明元数据不存在；此时 security 将完全不会安装任何内容。

在 Fedora 上，dnf 5 重命名了该单元。新名称是 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 语法，因为其中大部分语法仍会直接传递给 dnf。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 为两个版本分别发布了不同的仓库命令，这最能清楚地说明问题。在 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 和中间版本在服务器上的区别，本质上是在 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 的等效功能？

没有。个人软件包归档是 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>。如果启用的软件仓库中已不存在旧版本的软件包，撤销操作就会失败，因为 dnf 没有可用于重新安装的软件包。撤销操作也只能还原软件包更改。升级重写的配置文件，或服务首次启动时迁移的数据库，都会保持当前状态。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 仅用于兼容；同时应优先使用 dnf config-manager，而不是较旧的 yum-config-manager 二进制文件。

为什么 dnf remove 要删除这么多软件包？

因为 dnf 会在同一个事务中删除其他软件包都不再需要的依赖项，而 apt remove 会保留这些依赖项，直到您单独运行 apt autoremove。因此，在 Ubuntu 上看似很小的软件包删除操作，在 Rocky Linux 上可能会列出很长的清单。该清单通常是正确的，但确认前应先查看。如果清单中有您希望保留的软件包，请先显式安装它，使 dnf 将其记录为明确需要的软件包。