DNF and Yum in Fedora

Did you know...?

LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

The 0.4.10 release of the DNF package manager—slated to eventually replace Yum—was the proximate cause for a sizable fedora-devel mailing list thread, but it would seem a bit premature to get too concerned about the switch. The switch is targeted for Fedora 22, which is unlikely to be delivered before 2015. But the discussion does provide an opportunity to look in on DNF to see where things stand since we last looked at the package manager in June 2012.

Yum is, of course, the current package manager for Fedora (and RHEL). It started out as the Yellowdog Updater (YUP for Yellow Dog Linux), but was rewritten (and renamed) to "Yellowdog Updater, Modified" or Yum in the early 2000s. Yum manages packages in the RPM format, so it became the package manager of choice for several RPM-based distributions. But Yum has fairly slow performance and high memory usage; code "cruft" has increased over time as well. According to Martin Langhoff, much of that is due to backward compatibility requirements that Yum has—a rewrite could dispense with many of those.

There is another reason that Yum is being targeted for replacement: it uses its own, iterative dependency-resolution mechanism. More recent (and better performing) schemes for doing dependency resolution exist, and one, in the form of the satisfiability solving library libsolv, has been adopted by several other projects (including, of course, libsolv's origin: openSUSE's zypper package manager).

DNF does not use libsolv directly, but via the hawkey library. The move to hawkey has a number of benefits, including providing an API for languages other than Python. The existing Yum dependency-resolution code can be called from elsewhere, but only easily from Python. Programs like PackageKit that are written in C or other languages must either run Yum to do that work, or come up with their own dependency resolution. So, PackageKit, the Anaconda installer, and other programs that need to determine the dependencies for packages can use hawkey (and thus libsolv) for that.

Unlike Yum, DNF will explicitly define its API. The API for Yum has grown in an ad hoc fashion over the years, so revamping Yum will allow removing some parts of the API moving forward.

Eventually, DNF (which, contrary to many jokes, doesn't stand for anything) will be renamed to Yum, even though it is not a drop-in replacement. There are commands and features of Yum that will not be supported by DNF. Therein lies some of the unhappiness seen in the mailing list thread.

DNF complaints

Harald Reindl noted an announcement from DNF project lead Aleš Kozumplík that invited Fedora users to start trying out DNF in place of Yum. Reindl is concerned that various important Yum features are getting left by the wayside and that DNF will replace Yum without being ready. In another post, he likened it to the GRUB2 and systemd transitions, which were done before those components were ready, he said.

In particular, Reindl believes that the kernel package should be treated specially, as it is in Yum, rather than treated like any other package, as DNF does. A "yum erase kernel" command will not erase (aka remove) the package for the currently running kernel, while the DNF equivalent (replace "yum" with "dnf") will remove all kernel packages, including the currently running kernel. That will likely leave the system in an unbootable state, which is probably not what the user intended.

Kozumplík does not seem worried about the problem, though. He added an entry in a page describing differences between DNF and Yum indicating that there are no plans to treat the kernel package differently. He closed a bug filed about the problem as well. That didn't sit well with Reindl, but others were not particularly upset. Chris Adams explained that the Yum behavior was actually rather surprising to him:

But, as Rahul Sundaram pointed out, it is not just the kernel package that needs protection. The Yum protected_packages setting is ignored by DNF, but Sundaram thinks that may need to be reconsidered:

Matthew Miller noted that protected_packages was originally put into Yum as a plugin, "but then it proved itself in real use and became built-in". So suggesting that the feature could be added to DNF via plugin, as the DNF documentation does, brings it all full circle—except that there is no protected_packages-like plugin for DNF, at least yet.

Another issue is the keepcache option, which has been dropped from DNF. It would keep a copy of downloaded RPM files in the cache, rather than deleting them after installation. The DNF documentation indicates that there are "no real use cases", but several in the thread disagreed. Kevin Kofler said that he changes the Fedora Yum default (keepcache=0) on every machine he installs. A bug filed on the problem lists additional use cases. Kozumplík's response indicated that keepcache may return.

While some of the missing features are clearly important (and Sundaram has collected a list of problems he believes need to be addressed before any switch could be made), there is no huge rush. Fedora 21 is slated for August at the earliest, which would push Fedora 22 well into 2015—February or beyond. That is part of what caused the irritation displayed by some of the thread participants; it is just too early (at least in their minds) to be alarmed about the state of DNF. If it were three months into the Fedora 22 cycle, one would guess that things would be different.

Barring any serious bugs being found, DNF would seem to be in pretty good shape overall, as Sundaram's list (which includes all of the features that Reindl and others were complaining about) shows. Before it replaces Yum, there will still be opportunities to slow down that process and delay it into Fedora 23 or beyond. But a year is a long time and one suspects that the DNF team will have dealt with any problems by then. Filing bugs and trying to ensure they get addressed is quite reasonable at this point—in fact quite helpful to the team—but it is rather premature to get up in arms about the transition.