Yum Package Manager has been replaced by DNF Package Manager since many long-standing issues in Yum remain unresolved.
These problems include poor performance, excessive memory usage, slowdown for dependency resolution.
DNF uses “libsolv” for dependency resolution, developed and maintained by SUSE to improve performance.
It was written mostly in python, and it has its own way of coping with dependency resolution.
Its API is not fully documented, and its extension system only allows Python plugins.
Yum is a front-end tool for rpm that manages dependencies and repositories and then uses RPM to install, download and remove packages.
Both are used to manage packages on the rpm-based system (such as Red Hat, CentOS and Fedora), including installation, upgrade, search and remove.
Why would they want to build a new tool instead of fixing existing problems?
Ales Kozamblak explained that fixing issues was not technically feasible and that the yum team was not ready to accept the changes immediately.
Also, the big challenge is that there are 56K lines for yum, but only 29K lines for DNF, so there is no way to fix it, except the fork.
However yum was working fine and it was a default package management tool until RHEL/CentOS 7.
|S.No||DNF (Dandified YUM)||YUM (Yellowdog Updater, Modified)|
|1||DNF uses ‘libsolv’ for dependency resolution, developed and maintained by SUSE.||YUM uses the public API for dependency resolution|
|2||API is fully documented||API is not fully documented|
|3||It is written in C, C++, Python||It is written only in Python|
|4||DNF is currently used in Fedora, Red Hat Enterprise Linux 8 (RHEL), CentOS 8, OEL 8 and Mageia 6/7.||YUM is currently used in Red Hat Enterprise Linux 6/7 (RHEL), CentOS 6/7, OEL 6/7.|
|5||DNf supports various extensions||Yum supports only Python-based extension|
|6||The API is well documented so it’s easy to create new features||It is very difficult to create new features because the API is not properly documented.|
|7||The DNF uses less memory when synchronizing the metadata of the repositories.||The YUM uses excessive memory when synchronizing the metadata of the repositories.|
|8||DNF uses a satisfiability algorithm to solve dependency resolution (It’s using a dictionary approach to store and retrieve package and dependency information).||Yum dependency resolution gets sluggish due to public API.|
|9||All performance is good in terms of memory usage and dependency resolution of repository metadata.||Overall performance is poor in terms of many factors.|
|10||DNF Update: If a package contains irrelevant dependencies during a DNF update process, the package will not be updated.||YUM will update a package without verifying this.|
|S.No||DNF (Dandified YUM)||YUM (Yellowdog Updater, Modified)|
|11||If the enabled repository does not respond, dnf will skip it and continue the transaction with the available repositories.||If a repository is not available, YUM will stop immediately.|
|12||dnf update and dnf upgrade are equals.||It’s different in yum|
|13||The dependencies on package installation are not updated||Yum offered an option for this behavior|
|14||Clean-up Package Removal: When removing a package, dnf automatically removes any dependency packages not explicitly installed by the user.||Yum didn’t do this|
|15||Repo Cache Update Schedule: By default, ten minutes after the system boots, updates to configured repositories are checked by dnf hourly. This action is controlled by the system timer unit named “/usr/lib/systemd/system/dnf-makecache.timer”.||Yum do this too.|
|16||Kernel packages are not protected by dnf. Unlike Yum, you can delete all kernel packages, including one that runs.||Yum will not allow you to remove the running kernel|
|17||libsolv: for solving packages and reading repositories.|
hawkey: hawkey, library providing simplified C and Python API to libsolv.
librepo: library providing C and Python (libcURL like) API for downloading linux repository metadata and packages.
libcomps: Libcomps is alternative for yum.comps library. It’s written in pure C as library and there’s bindings for python2 and python3
|Yum does not use separate libraries to perform this function.|
|18||DNF contains 29k lines of code||Yum contains 56k lines of code|
|19||DNF was developed by Ales Kozumplik||YUM was developed by Zdenek Pavlas, Jan Silhan and team members|
In this guide, we have shown you several differences between DNF and YUM.
If you have any questions or feedback, feel free to comment below.
5 Comments on “What is the difference between DNF and YUM?”
Like many open source efforts and ‘itches to scratch,’ there were already multiple projects in place to possibly replace YUM with. Heck, APT-RPM has been around forever as well, and there have been others.
Even systemd — let alone journald — didn’t immediately ‘win out’ at Red Hat, among countless efforts (yes, systemd was NOT the only Red Hat development) The adoption of systemd — and journald — really came from finally addressing some of the most outstanding 10+ and even 20+ year ‘bugs’ Red Hat customers had (especially a ’90s bug in the case of journald) that finally addressed them.
But … what really pushed DNF to the forefront more than probably anything, when it came to continuing to update YUM which goes back to the late ’90s and the Yellowdog (PowerPC port of Red hat Linux), was the tragic loss of Seth Vidal. That really made Red Hat wonder if YUM ‘v4’ shouldn’t just be DNF and … as it came to be … was.
Yellowdog Updater Modified (YUM) has radically changed from its early days and, for the most part, DNF is a ‘drop in replacement’ for it. People still use the ‘yum’ command and get ‘dnf’ without much fuss.
You are right.
I am really tired of finding always new names for software functions which are more or less the same just changing release version of Linux. What do you think that we are doing during our days? Just re-learning to use the different packages to accomplish the same tasks? BTW the Gnome interface in Centos 8 is perhaps the worse Graphical environment I ever saw in my professional life!
I kind of hear you on that – thing is this is the price to be paid for used open software. You are not compelled to use dnf, you can stick to yum or even rpm itself, if you choose, at the expense of convenience, performance and complexity. Additionally, if you don’t like Gnome, and I don’t much care for it though it has grown on me somewhat and is fine to use, simply find a GUI you like. I like KDE Plasma, but that is just one of many options. Play around – try Mate or Cinammon, or even, for an efficient and lightweight experience, Xfce…
You are right too )))