We are going to learn the difference between DNF and YUM package managers in this article. But first, let’s take a look at what both these YUM and DNF are.
Table of Contents
What is YUM?
YUM stands for YellowDog Updater Modified. It is a package manager used for installing, updating, or removing software packages in the Red Hat Enterprise Linux system. While installing, updating, or removing software packages YUM performs dependency resolution.
The YUM package manager still works on RedHat based Linux 6/7 (RHEL), CentOS 6/7, and OEL 6/7. But on the newer distributions, it is not recommended to use this package manager.
What is DNF?
DNF stands for Dandified YUM and is basically an improved version of the YUM package manager. It offers more features while installing, updating, or removing software packages in a RedHat based Linux system.
CentOS 8 offers this package manager by default.
Need for a New Package Manager
Well if DNF is just an updated version of YUM, why not update YUM instead of introducing an entirely new package manager?
The YUM package manager was facing issues that had been persisting over a long period of time. Some of these issues include but are not limited to poor performance, excessive memory consumption, and slow dependency resolution.
Also, the YUM package manager had 56k lines of code so fixing these issues was not child’s play. So instead of going through the usual time-consuming process of trial and error to fix the YUM package manager, a new package manager was introduced which was free of all the problems existing in its predecessor.
So DNF was introduced which utilizes
libsolv for dependency resolution. Compared to DNF, YUM used a public API for dependency resolution. Even though DNF was introduced to replace YUM there are a lot of crucial functionalities that are similar in both. One of these is Repo Cache Update Schedule.
Using Repo Cache Update Schedule, DNF will check for updates to configured repositories every hour. A time unit
/usr/lib/systemd/system/dnf-makecache.timer watches over this action. This function was also the same in the YUM package manager.
Differences between DNF and YUM
Now that we know why was a new package manager introduced in Linux, we can move forward and look at the differences between these two package managers.
For better understanding and clarity we are going to compare the differences of both these package managers side by side. This way we can compare both package managers while also learning more about them.
The below table compares each attribute of the 2 package managers.
|DNF Package Manager||YUM Package Manager|
|1||For dependency resolution, DNF uses
||YUM utilizes a public API for dependency resolution.|
|2||API has been fully documented which makes it easy to develop new features.||No proper API documentation is available which highly hinders the process of development..|
|3||Languages used for development are C, C++, and Python.||It was developed in Python.|
|4||DNF operates in Fedora, RHE Linux 8, CentOS 8, and Mageia 6/7.||YUM operates in RHE Linux 6/7, CentOS 6/7, and OEL 6/7.|
|5||It supports multiple extensions.||Only supports extensions based in Python.|
|6||Utilized less memory while synchronizing metadata of the repositories.||Excessive memory consumption when synchronizing metadata of the repositories.|
|7||Uses a satisfiability algorithm for faster dependency resolution.||Slow dependency resolution because of a public API.|
|8||During the DNF update, any package containing irrelevant dependencies will not be updated.||YUM will update a package even if it contains irrelevant dependencies.|
|9||If a repository doesn’t respond during a transaction, DNF will skip and continue using the available repositories.||If YUM comes across an unresponding repository during a transaction, it immediately stops.|
|10||While deleting a package, DNF will automatically remove any dependency packages that were not specifically installed by the user.||YUM does not have this functionality.|
|11||DNF does not protect Kernel packages. That means you can delete Kernel packages, even the one that is running.||YUM protects Kernel packages and does not allow to delete them.|
|12||DNF is compiled of 29k lines of code.||YUM is compiled of 56k lines of code.|
|13||dnf update and dnf upgrade do the same thing.||yum update will update all the system packages but will not remove obsolete packages on the other hand, yum upgrade will remove obsolete packages while updating system packages.|
We talked about how DNF has a better mechanism for dependency resolution. Let’s take a brief look at what libraries are used by DNF to perform better dependency resolution.
- libsolv: this library is utilized by DNF package manager for reading repositories and solving packages.
- hawkeye: this library provides C and Python API to libsolv.
- librepo: this library provides C and Python API to download metadata and packages related to the Linux repository.
- libcomps: this library ensures the same functionality in DNF as
yum.compslibrary in YUM package manager.
Let’s take a brief look at what are some of the benefits DNF package manager offers to end-user as well as developers.
The benefit for the end-user in making the switch from YUM to DNF means a more authentic experience. And DNF is able to offer this reliability because of its better dependency-solving ability.
Users will not face the issue that while installing a package the system gets stuck on resolving a dependency. DNF is smarter in that sense, thus enhancing the user experience.
Also installing or upgrading will be faster and that too with less memory consumption during package installation. This also leads to a better user experience. Especially considering that the YUM package manager was getting slower and slower for running upgrades.
For developers, moving to DNF means faster and more reliable work since all exposed APIs are well documented. Another good thing about DNF is that C will still implement it.
Like hawkeye and librepo more C-based APIs will be released in the future. This is a huge plus for development since C is still widely used.
Could be worth mentioning, that in more recent systems (not sure since when), both yum and dnf actually link to the same executable, dnf-3 – so it does not matter which one is used.