DNF5 5.4：C++ 重写的包管理器，去掉 Python 依赖

5.4 发布 2026-09-20 21:55 · 更新 2026-09-23 21:18 系统工具免费开源 4

Fedora 上的 dnf，悄悄换了一副骨架

在 Fedora 41 之后的系统里敲 dnf，实际执行的多半已经不是当年那个用 Python 写的 dnf 了。DNF5 是同一个项目的重写版本，改用 C++ 实现，从 Fedora 41 起成为默认包管理器，/usr/bin/dnf 如今只是一个指向 dnf5 的符号链接。项目由 rpm-software-management 组织维护，许可证为 GPL-2.0-or-later。

去掉 Python 依赖，省下来的是体积和启动开销

旧版 dnf 建立在 Python 之上，启动时要先拉起解释器再加载一批模块；DNF5 把这些逻辑搬进编译后的库，命令行工具本身不再依赖 Python。按 Fedora 官方发布说明给出的数字，在一个空容器里安装这套工具链，体积比原来小约 60%。查询类操作的收益更直观：repoquery 这类列出仓库可用包的命令，处理速度约为原来的两倍，列依赖、解析长参数列表的等待时间也跟着缩短。

具体改了哪些地方

三件工具合并

原来的 dnf、microdnf 以及图形化后端各自维护缓存，元数据被重复存了好几份；换成 dnf5 与 dnf5daemon 之后共用同一份元数据，这部分冗余被抹掉。

插件随主程序发布

插件不再单独打包，和核心功能装在一起，升级时不容易出现版本对不上的情况。

API 收敛成一个

管理软件包、操作仓库、求解依赖这三类接口合并进同一个组件，脚本语言的绑定统一由 SWIG 提供，命名风格也做了统一。

输出与文档

事务表格的信息更细，脚本片段的冗长输出按包名重定向进日志文件，每条命令配了独立的 man 手册，bash 补全同样做了增强。

迁移时值得留意的两件事

一是历史数据库不互通。dnf 与 dnf5 各记各的事务历史，格式也不一样，在 dnf 里装过的包，dnf5 侧看不到这次操作。不过 dnf5 第一次执行事务时会尝试从 dnf 读取并转换系统状态，尽量保住「这个包是当初作为依赖装上的」这类信息，免得后续把依赖包当成用户主动安装的软件，从而错过回收。

二是企业版还在用旧版。RHEL 9、Rocky Linux 9、AlmaLinux 9 与 RHEL 10 目前的默认包管理器仍是原来的 dnf，DNF5 尚未在这些系统上接替。截至 2026 年 9 月，最新发布的是 5.4.0.0；对普通 Fedora 用户来说直接敲 dnf 就好，想明确区分时可以写成 dnf5。

为了降低迁移成本，dnf5 为常用命令与选项保留了兼容别名，原来写顺手的用法基本照旧。python3-dnf 与 libdnf 两套旧库也还留在系统里，可以和 dnf5 并存，只是不建议两边交替改动已安装的软件，因为系统状态并不共享。