apt 转 dnf：Rocky、AlmaLinux 和 Fedora 命令对照

简短回答

从 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 及所有基于 Debian 的发行版使用 apt。在 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 中，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/ 中，密钥则是 .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 用户切换后最常怀念的功能。

此功能有实际限制。依赖它之前，必须了解这些限制。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 中的等效机制是将名称、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 的符号链接。使用 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 将其记录为独立需要的软件包。