来自红帽的丹尼尔·马赫 关于DNF 5包管理器的开发开始，其中用Python实现的DNF逻辑将转移到用C++编写的libdnf库中。 DNF 5 计划在 Fedora 33 开发过程中于 2020 月开始测试，之后将于 2021 年 4 月添加到 Rawhide 存储库，并于 4 年 8 月取代 DNF XNUMX。DNF XNUMX 分支的维护将按原样继续进行用于红帽企业 Linux XNUMX。
值得注意的是，该项目已经达到了这样的状态：在不破坏 API/ABI 级别的兼容性的情况下，几乎不可能继续开发代码。 这主要是由于 PackageKit 的相关性以及在不更改“libhif”API 的情况下开发 libdnf 的可能性。 与此同时，尽管有意更改 API，但据说维持命令行界面和 API 级别的向后兼容性是主要优先事项。
DNF 中对 Python API 的支持将被保留，但用 Python 编写的业务逻辑将转移到 libdnf (C++) 库，这将确保发行版中包管理器的操作相同。 开发将以C++ API为中心，Python API将基于其以包装器的形式自动生成。
Go、Perl 和 的绑定
红宝石。 C++ API 稳定后，将在其基础上准备 C API，并将 rpm-ostree 转移到该 API。 Python API 将被删除并替换为 Python API。
DNF的核心功能将被保留。 由于测试套件规模较大（约 1400 个测试），预计 API 返工不会影响最终用户的命令行界面。 参数解析和输出可能会略有变化，但这些变化将被详细记录。 精简版 ，用于容器中，计划实现DNF功能的子集；不考虑实现功能上的完全对等。
而不是 将创建一个新的 DBus 服务，提供用于管理软件包和图形应用程序更新的界面。 该服务计划从头开始开发，因此其创建可能需要大量时间。 PackageKit 最近没有开发，并且由于失去相关性而自 2014 年以来一直处于维护模式。 随着 Snaps 和 Flatpak 系统的进步，发行版对 PackageKit 失去了兴趣，例如，它在构建中不再可用 。 包管理的抽象层主要由本机 GNOME 和 KDE 应用程序控制中心提供，它们允许在个人用户级别安装 flatpak 包。 用于获取已安装软件包列表的统一系统 API 不再像以前那么有用。
来源： opennet.ru