Fedora Linux 39 计划默认使用 DNF5 以获得更好的性能
Fedora 工程和指导委员会 (FESCo) 宣布在 Fedora 39 中负责的团队可能会取代 DNF, libdnf 和 dnf-自动 c使用新的 DNF5 打包工具和 libdnf5 支持库. DNF5 应该改善用户体验并为在 Fedora Linux 上管理软件提供更好的性能。
DNF 是一个软件包管理器 它在 Fedora 中安装、更新和删除软件包，是 YUM（Yellow-Dog Updater Modified）的继承者。 DNF 通过自动检查依赖关系并确定安装包所需的操作，使维护包变得容易。 此方法无需使用 rpm 命令手动安装或更新包及其依赖项。
关于《DNF5》的新功能，比较突出的有以下几点：
- 无需 Python 的完整包管理器
- 最小系统
- 快点
- 替换 DNF 和 Microdnf
- 整个软件管理堆栈的统一行为
- 新的 Libdnf5 插件（C++、Python）将适用于 DNF5 和 Dnf5Daemon。
- 共享设置
- DNF/YUM 已经发展了几十年，受到多种风格和命名约定（选项、设置、选项、命令）的影响
- 如果它内置在 Desktop 中，它可以为 RPM（一个独特的 PackageKit 后端）提供 PackageKit 的替代方案。
- 与模块化和组合组的兼容性
- 代码库的重要改进
- 从历史数据库和 /etc/dnf/module.d 中分离系统状态
在 dnf-4 中，已安装包的列表 由用户和已安装组的列表，以及这些组的已安装包列表， 被计算为历史的聚合 的交易。 在 dnf5 中会单独存储，它有多个优点，其中最重要的是历史数据库将仅用于信息目的，并且不会定义系统的状态（它偶尔会损坏等）。 /etc/dnf/module.d 中存储的数据不应该是用户可写的，并且其格式不充分（缺少有关已安装包和已安装配置文件的信息）。
DNF5 仍在开发中 并且某些功能或选项尚不可用。 然而 在实现模块化方面还有很多工作要做，与系统历史和状态相关的内部数据存储，以及文档和手册页。 DNF5 可以通过每晚上游构建从存储库中进行测试。
DNF5 将弃用 dnf、yum、dnf-automatic、yum-utils 和 DNF 插件 （核心和附加功能）python3-dnf 和 LIBDNF（libdnf，python3-hawkey）将与 fedora-obsolete-packages 一起被弃用，另外它将提供指向 /usr/bin/dnf 的符号链接，因此用户会将替换视为更新以有限但记录在案的语法更改为 DNF。 DNF5 将提供一些受支持的命令别名和选项，以提高 DNF5 的采用率。
变更提案总结如下：
- 新 DNF5 将显着提升用户体验和性能. 此替换是 Fedora 软件管理堆栈升级的第二步。 如果不进行此更改，将有几个基于不同库（libdnf、libdnf5）的软件管理工具（DNF5、旧 Microdnf、PackageKit 和 DNF），它们将提供不同的行为并且不会共享历史记录。 DNF 也有可能只有有限的开发人员支持。 DNF5 的开发在 2020 年的 Fedora-Devel 列表中公布。
- DNF5 为更小的系统移除 Python 代码，更快的性能，并取代现有的 DNF 和 microdnf 工具。 DNF5 还统一了软件管理堆栈的行为，引入了一个新的守护进程作为 PackageKit for RPM 的替代品，并且应该更有能力。 期望更快的存储库浏览、查找操作、RPM 查询和元数据共享性能。
变更提案仍需获得批准 由 Fedora 工程和指导委员会负责，但鉴于 Red Hat 参与了 DNF(5)，可以假设它将被批准并有望在 Fedora 39 周期内及时完成
数据来源： https://fedoraproject.org