DNF, which may or may not replace Yum

Fedora's Engineering Steering Committee (FESCo) recently voted to approve an additional feature for Fedora 18: a new alternative package manager called DNF. The primary author intends for DNF to replace Fedora's current package manager, Yum, but there are questions as to when it will be ready and why starting over is preferable to updating the existing code.

A handful of news sites reported DNF as "the" new package manager for Fedora, which might lead one to conclude that it will be the default option. However, DNF is only approved for inclusion in Fedora 18, as it does not have feature-parity with Yum and is still in heavy development. Yum will remain the system package manager, and may for several more releases.

DNF is the creation of Red Hat's Aleš Kozumplík, and is a fork of Yum 3.4 that uses his own hawkey library to resolve package dependencies. Like Yum, DNF sits on top of the lower-level rpm package installer; its purpose is to simplify package installation, update, and removal by automatically calculating dependencies and handling the management of dependent packages. The moniker "DNF" officially stands for nothing, and was chosen by Kozumplík solely as a placeholder, although the choice prompted humorous responses that it stood for un-complimentary phrases like "Did Not Finish" or the oft-maligned Duke Nukem Forever. Hawkey itself is a wrapper around the libsolv dependency resolver from openSUSE.

Some of the goals described on the wiki page include providing API access to languages in addition to Python (which is currently Yum's only option), a "strict" API, and better performance. Migrating the package manager to libsolv is the primary goal, however, with an eye toward eventually using libsolv as the dependency solver for RPM itself, as well as making it available to other programs that handle package management, such as the installer. For users, a libsolv-powered DNF's principal advantage over Yum is expected to be its speed. At FUDCon in February, for example, Yum was described as being four times slower than untar, which no one seems to regard as acceptable.

Libsolv gains its advantage by using a modern satisfiability-solving algorithm (or "SAT solver"), rather than the ad-hoc dependency checking methods employed by other major Linux package managers. Libsolv's documentation observes that most package managers are optimized to find updates to currently installed packages, with extensions tacked on to handle other situations, resulting in slow and unpredictable code. Libsolv uses a reimplementation of the open source Minisat solver, and has been adopted by openSUSE's Zypper package manager.

Integration with Fedora

DNF uses the more modern libsolv for improved dependency solving, but it does not implement all of Yum's other features. The missing functionality generated some feedback from administrators who were upset that some of the features they depend on had evidently been marked as deprecated. For example, Yum has a "history" function that allows the user to investigate logged installation and update actions, and even roll them back, but the feature was listed on DNF's features considered for dropping page. When fans of the feature complained about its removal, Kozumplík agreed to implement it in a future version.

DNF also lacks PackageKit integration, which PackageKit maintainer Richard Hughes cited as a major problem during the FESCo debate about approving the feature. Others in the discussion were unclear as to the justification and plans for DNF to replace Yum. Bill Nottingham asked why a fork was necessary, and Matthew Garrett asked:

Distinct from the issue of advertising DNF's readiness too soon is the concern that Kozumplík appeared to have launched the project without first attempting to implement his changes within the main Yum trunk or working with the Yum team. Yum developer Tim Lauridsen asked on the desktop-devel mailing list:

Kozumplík replied that a fork was required to clean up the Yum API; deprecating legacy interfaces without worrying about simultaneously preserving backward compatibility. He also said that he is collaborating with the Yum team, which Seth Vidal called a contradiction, considering Lauridsen's question:

The future of solving

Of course, maintaining the delicate balance between paid-company-developers and community developers is a challenge on which most corporate distributions spend a lot of time. At least the two camps appear to be talking now. Doubtless there is interest in the improvements offered by a libsolv-based backend from the Yum project, particularly as other pieces of the Fedora infrastructure (including rpm itself and the installer) move toward it. Libsolv is gaining supporters among other projects as well (Hughes, for instance, is also the author of the alternative package manager zif, and indicated he was planning to migrate it to libsolv in the future). There does not appear to be a plan to migrate apt or apt-rpm to libsolv, but there has been interest in writing a new SAT solver to replace apt's current dependency resolver.

But agreement on the goal does not make the process any less arduous; there are inherent difficulties in replacing a piece of software as close to the core as Yum. Dependency resolving is complicated by the number of options an RPM package can declare, such as specific versions of some libraries or "recommended" packages that a user might select (thus adding still more dependencies to the puzzle). There are also scenarios where a user wants to swap out one package for another, and would prefer to leave the common dependencies in-place in order to cut down on time required. Despite the fact that openSUSE has been using libsolv in its own package manager Zypper, hawkey and DNF will require a lot of testing to get all of the corner cases correct. Until then, Fedora users can count on Yum staying right where it is.