Fedora Linux 开发人员打算将发行版转移到新的 Microdnf 包管理器，而不是当前使用的 DNF。 迁移的第一步将是计划在 Fedora Linux 38 发布时对 Microdnf 进行重大更新，其功能将接近 DNF，在某些方面甚至超越它。 值得注意的是，新版本的Microdnf将支持DNF的所有基本功能，但同时保持高性能和紧凑性。
Microdnf和DNF的关键区别在于使用C语言进行开发，而不是Python，这可以让你摆脱大量的依赖。 Microdnf 最初是作为 DNF 的精简版本开发的，用于 Docker 容器，不需要安装 Python。 现在Fedora开发者计划将Microdnf提升到DNF的水平，并最终用Microdnf完全取代DNF。
Microdnf 的基础是 libdnf5 库，作为 DNF 5 项目的一部分开发。DNF 5 的主要思想是用 C++ 重写基本的包管理操作，并将它们移动到一个单独的库中，并围绕此创建一个包装器保存 Python API 的库。
新版本的 Microdnf 还将使用后台 DNF Daemon 进程，取代 PackageKit 功能，并提供在图形环境中管理软件包和更新的界面。 与 PackageKit 不同，DNF Daemon 仅提供对 RPM 格式的支持。
第一阶段实施的Microdnf、libdnf5和DNF Daemon计划与传统DNF工具包并行交付。 项目完成后，新捆绑包将取代 dnf、python3-dnf、python3-hawkey、libdnf、dnfdragora 和 python3-dnfdaemon 等软件包。
Microdnf 优于 DNF 的领域包括： 更直观地指示操作进度； 改进了事务表的实现； 能够在报告中显示由包中内置的脚本生成的已完成交易信息； 支持使用本地RPM包进行交易； 更先进的 bash 输入补全系统； 支持运行 builddep 命令，而无需在系统上安装 Python。
将发行版切换到 Microdnf 的缺点之一是内部数据库结构发生变化，并将数据库处理与 DNF 分开，这将不允许 Microdnf 看到在 DNF 中执行的包的交易，反之亦然。 此外，Microdnf 并不打算在命令和命令行选项层面保持 DNF 中 100% 的兼容性。 行为上也会出现一些差异。 例如，删除包不会删除其他包未使用的关联依赖项。
来源： opennet.ru