从 dnf 迁到 dnf5 的实操差异

为什么要专门讲迁移

Fedora 上 dnf 这个命令背后换过实现。日常装机卸包几乎无感，但插件、脚本与一部分子命令写法会变；迁移的成本不取决于命令有多少，而取决于你的自动化里沉淀了多少「照着旧输出写的判断」。本页按「先确认、再核对、后改写」的顺序给出路径。

先确认你在 dnf4 还是 dnf5 上

Fedora 41 起默认使用 DNF5；DNF5 的命令参考由官方单独维护在 dnf5.readthedocs.io，不在 Fedora Quick Docs 里。

所以迁移第一件事不是改脚本，而是把基线记录下来：

dnf --version          # 输出会显示当前 dnf 背后的实现与版本

命令与输出变化：按官方文档核对

官方 Quick Docs 提供《Using the DNF software package manager》作为 dnf 用法基线，另有《APT command equivalents on Fedora with DNF》供换习惯的人对照。 官方基线文档里给出的是各子命令的标准写法（例如 dnf versionlock add / delete / list / clear 这一组），迁移时把它当作「同一件事在新环境里怎么写」的第一参照，而不是凭印象改。

dnf5 的官方命令参考按命令逐条列出，覆盖 Advisory / Autoremove / Check / Check-Upgrade / Clean 一直到 Swap / System-Upgrade / Versionlock 等一大批子命令。这份清单就是你脚本的检查表：

脚本里的动作	迁移时先确认什么
装、卸、升级	Install / Remove / Upgrade / Downgrade 的参数与输出是否还符合你的解析逻辑
事务与审计	History / Do / Replay / Offline（离线事务）是否还走同一条路径
仓库与元数据	Repo / Repoquery / Makecache / Clean 的参数变化
自动化巡检	Check / Check-Upgrade / Advisory 这类判断型子命令的返回与输出

常用脚本改写

命令之外，真正决定迁移工时的是脚本结构。三条纪律：

把 dnf 调用收敛到一层：所有 dnf 调用集中进一个封装函数或变量，迁移时只改一处，而不是在几十个脚本里 grep 替换。
不要解析人类可读输出：判断建立在退出码与明确的子命令上。两代实现之间的输出差异以官方《Changes between DNF and DNF5》为准——你的正则不会比它更权威。
在目标版本上先跑一遍：用隔离环境按目标版本验证，别在 F44 上改完就假设 F40 也能跑。

插件与扩展点：迁移最容易踩的地方

官方 dnf5 文档站把 《Tutorial: Writing Plugins》、《LIBDNF5 Plugins》、《Tutorial: API changes between DNF and DNF5》、《Tutorial: Language Bindings》 单列成章节——插件与 API 层是两个实现之间差异最集中的地方，依赖插件的行为要逐个确认。

系统 Python 的约束、打包与共存方式以官方 Packaging Guidelines 的 Python 章节为准；不要用 pip 往系统 Python 里塞依赖来补功能。 自动化里凡是靠 Python 层面接进包管理器的做法，迁移前按这份指南重新评估：能在隔离环境里做的，就放进Fedora 工具链与多版本共存描述的隔离方案里，而不是动系统 Python。

回退到 dnf4 前要确认什么

回退不是一条命令的事，先确认三件事：

你要回退的是哪个层面：只是某个子命令的写法，还是整个包管理器的实现？前者靠改写脚本解决，后者才是替换实现。
回退会带走什么：系统升级、离线事务、插件这些路径在两代实现下来源不同（见用 system-upgrade 做版本间升级），回退实现等于同时换了它们的后端。
变更与迁移的官方口径：以 dnf5 文档站的《Changes between DNF and DNF5》与《Migrating from DNF to DNF5》为准。