Yum vs. Dnf: All You Need To Know

Those of you who work on Fedora, CentOS, or RHEL are familiar with yum. Fedora users might have forgotten yum altogether because it was replaced by dnf so long ago. But other, downstream releases like RHEL and CentOS, took another four years to catch up and continued using yum. Dnf is yum’s replacement and is superior in every way. But it can be hard to switch to another package manager, so here are all the ways in which dnf is superior to yum, and how you can make the transition.

How YUM Became DNF: Fedora -> RHEL ->CentOS

Fedora is the “pure” Linux version that’s community-driven, open source, and is the testing bed for all kinds of ideas. The community is supported by Red Hat, which uses Fedora to identify interesting developments and pursue them within the Fedora community. Once the ideas are refined and developed. Red Hat takes those features and integrates them into RHEL – Red Hat Enterprise Linux. This is the commercial version of Linux, for which Red Hat sells support, works with hardware vendors to certify hardware support, and guarantees support for the long term.

CentOS is the final step after RHEL. CentOS was essentially the free version of RHEL for a long time without the support.

Yum Moves from Fedora to RHEL to CentOS

Because of the above development pattern, when it came time to search for an alternative to yum, it was Fedora that took the plunge before the others. Dnf was first developed and tested on Fedora, which replaced yum way back in 2015 with Fedora 22. Only five years later, in 2019, did RHEL, and by extension CentOS, migrate away from yum to dnf. With RHEL 8 and CentOS 8, both operating systems replaced yum.

However, for compatibility reasons, as well as to give people the time to learn about dnf, the distributions still allowed users to invoke yum, but it was simply an invocation to dnf in the background. Operationally, therefore, dnf has effectively already replaced yum.

CentOS Stream Is Now Upstream of RHEL

CentOS 8 is the last “proper” CentOS version and going forward, Red Hat has instead created CentOS as a buffer between Fedora and Red Hat, with confirmed changes to the CentOS stream merged into RHEL. As a result, the CentOS stream has been using dnf in the background instead of yum for a long time.

As of now, there are no plans to discontinue yum from being an alias to dnf, but this might happen in the future, though I see no reason for the support to end.

Differences Between Yum and Dnf

Now that we know that we’ve been using dnf for some years, here are the actual differences in implementation between the two.

Improvements in Package Dependency

The biggest difference between yum and dnf is that the latter has a vastly improved package dependency resolution, leading to greater efficiency and a smaller memory footprint.

In Linux, when you install a package, it might have several “dependencies” – namely packages that must be installed for the requested one to function. These packages in turn might have dependencies. So when you install something, the software has to hunt down possibly thousands of other packages to create a “dependency tree”. With Linux packages becoming ever more complicated, and given the frequency with which packages are installed, modified, and removed, an increase in yum efficiency results in massive performance gains.

To make matters worse, new versions of packages are released all the time, meaning that yum also has to decide on the most appropriate version to install, particularly given that other packages in the system have their dependencies and you don’t want to replace a version of a package with another one, only for it to break an existing package’s functionality.

SAT Algorithms

The secret sauce that makes dnf work is called “a satisfiability algorithm”. I’d first heard of this when studying PNP problems but didn’t know that it could be applied to something like resolving dependency trees. The idea is that for every installation, there exists a combination of packages that resolve the tree, with the values of all packages in a given configuration set to one, and this “satisfies” the problem. For all other packages, the values are set to zero.

The satisfiability or SAT algorithm leverages the latest advancements in mathematics and programming, and its use in dnf provides a huge performance boost to the package installer.

Why Not Simply Rework Yum – Why the Need for a New Name?

Since the major differences between yum and dnf are in the backend, it’s reasonable to ask why we had to have a different package name. Couldn’t we have simply reworked yum in the background, kept the same name, and let us continue blissfully as before?

While this was a possibility, dnf was a massive enough change from yum that it was decided to call it something else entirely, DNF stands for “dandified yum”, so it wasn’t breaking away entirely from its roots. The entire code base was changed, and the developers wanted to introduce it to the community slowly so that both tools could be used side by side. They also wanted to get ahead of any possible compatibility issues, where the two programs were installed next to each other, and without a separate name, there would be multiple versions of yum that worked very differently, and this might have unforeseen impacts.

In short, while it was possible to simply change yum from within, the complications of maintaining two entirely different codebases for the same package and managing their interactions necessitated a different package entirely.

Differences in dnf and yum APIs

When using a scripting language to perform tasks such as listing existing repositories, dnf’s API usage is completely different compared to yum.

For example, to list installed packages using dnf, the script is:

import dnf

base = dnf.Base()
base.fill_sack()
query = base.sack.query().filter(name='nano')

for package in query:
     print(package)

While for yum, it’s:

import yum

yb = yum.YumBase()
search_result = yb.searchPackages(['nano'])

for package in search_result:
    print(package)

The first thing you notice is that yum code is simpler to understand. Even if you’re not familiar with package manager scripting, it’s obvious that you just need to create an object and populate the search results with an easily understandable function “searchPackages”. Dnf, on the other hand, appears unnecessarily complicated, with calls to a “Base” object to generate a query with filtered results.

But with the additional complexity of dnf, comes greater efficiency, and while yum is easier to use for simple stuff, dnf excels at more complex operations, thanks to its more structured approach, compared to yum’s more procedural model.

Conclusion

Dnf is a significant update to yum that’s been years in the making, ever since its introduction into the Fedora ecosystem in 2015. Since then, it’s slowly filtered down to RHEL and CentOS and is now the framework behind even the yum command itself. It’s faster with dependency resolution, and even though the API is more complicated for simple tasks, it shines in handling more advanced scenarios.

If you’re an average user, you wouldn’t notice too much difference, and you can continue using yum as before, even though it’s dnf in the background. If you’re a developer, or use scripting for package managers, you should brush up on the new way of doing things.