Around this time last year, Fedora 22 brought a major update for anyone working under the Fedora hood -- Yum was deprecated and replaced by DNF. It brings some significant changes:
- Faster, more mathematically correct method for solving dependency resolution
- A “clean”, well documented Python API with C bindings &
- Python 3 support
Isn’t this a Release by Another Name?
No, DNF marks a shift, and not just a fork to Python 3, C support and cleaner docs. The move to libsolv, librepo and a slim, planned API means Yum’s organic sprawl and bespoke depsolving are being phased out.
The shift solves old depsolving problems and readies DNF for some of the changes afoot in the devops world -- e.g. empowered and independent devops-ers who don’t want to reinvent the wheel on each deploy. Whether that warrants more than a major release is a bike-shed argument.
Fixing a Decade old Dependency Problems with Math!
Third-party dependency resolution has been a pain in the Red Hat world since RPMfusion and its ancestors began releasing their own tools. Check out this chain for some depsolving debates from Obama’s first 100 days:
...the add-on packages from Livna have a strict dependency on the Fedora package they were build for. That leads to trouble when the Fedora package and its add-on package get updated, as there is no single point in time for Livna to ship the add-on package as update without causing trouble for users: Yum might try to install the updated add-on package before the Fedora mirror yum chose offers the updated Fedora package (like in the example above) or vice versa…
* yum is the central piece of software in this game, thus it's easy to say "it needs to be fixed in yum; it needs to be taught to do a second look at the right place to find what's needed"...
DNF moves to libsolv to solve this with sound math: it looks for the right thing (search) and makes sure it fits in the right place (combinatorial satisfaction). Libsolv been in production in openSUSE and the underlying algorithm is not just sound, it’s very fast.
Solving combinatorials shouldn’t be a devops challenge, so this should free shops to move more developers “downstream” without fear that they’ll drown in custom depsolving methods.
Libsolv Means Never Having to say Skip-broken
Some Yum functionality is obviated by Libsolv. Since libsolv always skips broken dependencies, there is never a reason to affirmatively declare “skip-broken”. The same holds for quite a few other Yum functions. The result should be a faster, simpler process for most deployments and updates.
To achieve this, DNF hides dependency errors by default, routing through them in most scenarios and saving the metadata. This was, of course, the goal all along: a faster resolution tool with a lower memory footprint.
But moving fast can often break things, or ignoring broken things. In DNF’s first full-time year, there have been troubleshooting and inspection challenges. These mostly seem to stem from a lack of verbosity and libsolv abstracting away the dependency decision tree.
What to Watch
For teams looking for a complete replication of Yum’s verbosity, don’t hold your breath. The goal of DNF is speed and scalability, so the fixes are rolling out will build on libsolv, librepo and hawkeye and target fixes on know, specific needs -- such as the troubleshooting mentioned above, and critical areas like security.
For a high-level view of what hasn’t migrated yet, check out the Yum plugins in the changes docs. And to pay your respects to Seth Vidal, take a look at the Evolution of Dnf in this hypnotic gource visualization.
About Alex
Alex Entrekin served on the executive staff of Cloudshare where he was primarily responsible for advanced analytics and monitoring systems. His work extending Splunk into actionable user profiling was featured at VMworld: "How a Cloud Computing Provider Reached the Holy Grail of Visibility".
Alex is currently an attorney, researcher and writer based in Santa Barbara, CA. He holds a J.D. from the UCLA School of Law.