DNF 和 Yum 的区别，为什么 Yum 会被 DNF 取代？

由于 Yum 中许多长期存在的问题仍未得到解决，因此 Yum 包管理器已被 DNF 包管理器取代。这些问题包括性能差、内存占用过多、依赖解析速度变慢等。

DNF 使用 libsolv 进行依赖解析，由 SUSE 开发和维护，旨在提高性能。

Yum 主要是用 Python 编写的，它有自己的应对依赖解析的方法。它的 API 没有完整的文档，它的扩展系统只允许 Python 插件。

Yum 是 RPM 的前端工具，它管理依赖关系和资源库，然后使用 RPM 来安装、下载和删除包。

为什么他们要建立一个新的工具，而不是修复现有的问题呢？

Ales Kozamblak 解释说，这个修复在技术上是不可行的，而且 Yum 团队还没有准备好立即接受修改。

另外，最大的挑战是，Yum 有 56000 行代码，但 DNF 只有 29000 行代码。

所以除了分叉，没有办法解决。

不过 Yum 的运行情况还算可以。

DNF 目前在 Fedora、RHEL 8、CentOS 8、OEL 8 和 Mageia 6/7 中使用 YUM 目前在 RHEL 6/7、CentOS 6/7、OEL 6/7 中使用
API 有良好的文档，因此很容易创建新的功能 因为 API 没有正确的文档化，所以创建新功能非常困难
DNF 使用满足性算法来解决依赖关系解析（它是用字典的方法来存储和检索包和依赖信息） 由于使用公开 API 的原因，Yum 依赖性解析变得迟钝
从内存使用量和版本库元数据的依赖性解析来看，性能都不错 总的来说，在很多因素的影响下，表现不佳
DNF 更新：在 DNF 更新过程中，如果包中包含不相关的依赖，则不会更新 YUM 将在没有验证的情况下更新软件包
如果启用的存储库没有响应，DNF 将跳过它，并继续使用可用的存储库处理事务 如果有存储库不可用，YUM 会立即停止
清理删除的包：当删除一个包时，DNF 会自动删除任何没有被用户明确安装的依赖包 Yum 不会这样做
存储库缓存更新计划：默认情况下，系统启动后 10 分钟后，DNF 每小时会对配置的存储库检查一次更新。这个动作由系统定时器单元 dnf-makecache.timer 控制 Yum 也会这样做
内核包不受 DNF 保护。不像 Yum，你可以删除所有的内核包，包括运行中的内核包 Yum 不允许你删除运行中的内核
libsolv：用于解包和读取资源库。hawkey: 为 libsolv 提供简化的 C 和 Python API 库。librepo: 提供 C 和 Python（类似 libcURL）API 的库，用于下载 Linux 存储库元数据和软件包。libcomps: 是 yum.comps 库的替代品。它是用纯 C 语言编写的库，有 Python 2 和 Python 3 的绑定。 Yum 不使用单独的库来执行这些功能

via: https://www.2daygeek.com/comparison-difference-between-dnf-vs-yum/

作者：Magesh Maruthamuthu 选题：lujun9972 译者：wxy 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

原创文章，作者：ItWorker，如若转载，请注明出处：https://blog.ytso.com/49164.html

centosFedoralinuxpython