User: Password:
Subscribe / Log in / New account

DNF, which may or may not replace Yum

Did you know...? 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.

By Nathan Willis
June 27, 2012

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:

Is this intended to prototype functionality that'll head back to yum? Or is it going to sit there as an alternative and some time later we'll have a contentious argument about defaults?

FESCo eventually voted to approve the feature on the grounds that (as Miloslav Trmač put it) it was a "'we added a package, please come and play with it' kind of feature, not 'this is a change for everybody' kind of feature."

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:

Would it not be better to work with yum upstream to make the current yum depsolver more modular so you could plugin another libsolv based depsolver, instead of making a fork of yum and starts trashing the current API. There is a lot more to yum, that just solving dependencies. And making a fork there is not fully compatible will put a lot of work on your shoulders :) without the benefit on the work done by yum upstream :) like parallel download etc.

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:

Tim _IS_ a yum developer. That he felt surprised by this means you've only been communicating with yum devs on the internal red hat packaging team not in the community channels related to yum specifically. It would make good sense if you want to figure out what apis are important/matter to discuss this on the yum-devel mailing list at the very least.

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.

(Log in to post comments)

DNF, which may or may not replace Yum

Posted Jun 28, 2012 5:56 UTC (Thu) by patrick_g (subscriber, #44470) [Link]

> there has been interest in writing a new SAT solver to replace apt's current dependency resolver.

For Debian there is the Mancoosi research project
See also this interesting post about using external solver in apt-get.

DNF, which may or may not replace Yum

Posted Jun 28, 2012 6:59 UTC (Thu) by niner (subscriber, #26151) [Link]

Why start a completely new package manager based on zypper's dependency solving library and not simply use zypper!? IMHO zypper is overall the best package manager currently available. If yum has features zypper is lacking, they can be added much quicker than implementing a new package manager from scratch or rewriting yum to be based on libsolv.

Imagine Fedora and openSUSE moving closer and bundling their resources to work on the same package manager. Documentation and help suddenly available for both distributions. Now that would be nice.

But of course, it's NIH. So this can never happen...

DNF, which may or may not replace Yum

Posted Jun 28, 2012 9:34 UTC (Thu) by epa (subscriber, #39769) [Link]

A very good question. I also wonder what happened to the smart package manager from a few years back.

DNF, which may or may not replace Yum

Posted Jun 28, 2012 16:19 UTC (Thu) by jengelh (subscriber, #33263) [Link]

It was popular before zypper showed up. I guess smart rightfully died out, because it was even slower than yum. That is to say, if I have to wait for smart for on 45 minutes on a TM5800 CPU on a dist-upgrade for what "zypper dup" will do under a minute on the very same silicon, something is wrong. IIRC, smart was also a heuristics-based solver like most other implementations. It boasted on its then webpage to solve some cases that apt got wrong, and while that was true, I suppose it were these extended algorithms that eventually were able to drive the computation time to unbearable infinity.

DNF, which may or may not replace Yum

Posted Jul 11, 2012 15:52 UTC (Wed) by criswell (guest, #40091) [Link]

Smart's momentum seemed to take a hit when the lead developer was hired by Canonical and started working on apt related issues in Ubuntu. It's too bad, because you could do some really amazing things with the Smart API.

Way back when, I was the author of (the now orphaned) rpmstrap. I began working on an experimental rewrite of it using the Smart API and found I could do some pretty amazing things (also, scary things- like bootstrap a working system using a mixture of packages from RPM and DEB-based distros :-)

I always felt really sad that Smart never caught on more...

DNF, which may or may not replace Yum

Posted Jun 28, 2012 16:44 UTC (Thu) by jengelh (subscriber, #33263) [Link]

>Imagine Fedora and openSUSE moving closer and bundling their resources to work on the same package manager.

There was an effort to offer zypper as an installable:

Sadly, as so often happens in the Fedora realm, bugs are left languishing due to lack of interest, time, or support coverage ("uh, custom partitioning in the text install is not supported") to receive the necessary mentoring.

Well. RH-F-originating software is often regarded highly, and then perhaps integrated (systemd, sssd). But I wonder why this generally does not seem to work in the reverse direction :-/ Using libsolv is nice, but seems like a consolation prize for not going the route of modifying zypper.

DNF, which may or may not replace Yum

Posted Jul 1, 2012 12:04 UTC (Sun) by roblucid (subscriber, #48964) [Link]

Actually it did happen with RPM, at the developer level integrating changes and cooperating. Features like delta-rpm's eventually got included in Fedora.

Probably this happens because developing your own, gets more kudos, is more interesting and is much more sexy.. than integrating in someone elses code and then integrating changes back upstream.

As the package management, has been a key value added feature of distro's, bringing in a tool from outside, likely has high bar to clear. After all each resolver & update system has grown organically in it's own niche distro environment and been shaped by it.

Let's just hope, it doesn't get added into 'systemd' (*joke*)

DNF, which may or may not replace Yum

Posted Jun 29, 2012 3:35 UTC (Fri) by ezyang (guest, #62208) [Link]

I was under the impression that explanations for unsatisfiability was an (unsexy) open problem, so I'm a bit surprised that this hasn't been more of a problem for people wanting to use SAT solvers to solve their package dependency problems.

Copyright © 2012, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds