Hello and let us present you the 0.4.10, which brings enhancements to the plugin mechanism and fixes to eleven bugzillas.
The plugins can now use two new hooks triggered after the sack is loaded and when a transaction is finished. Further power of the DNF plugins is going to be in their ability to register their own CLI commands. For instance, work is underway to implement dnf kickstart as a plugin to install packages given by a kickstart file
As usual, the release notes give the full story of enhancements and fixes in this release.
Fedora specific note: unfortunately due to some problems in unrelated packages, the Rawhide build is not available yet. We hope to be able to make one the next week.
Seeing many users confused about the difference in the outputs and transactions of running yum update versus dnf update I feel I should explain that this is the expected result and not a bug. One reason is that DNF does not list update candidates as it explores them. More frequently however the reporter means actual difference in the proposed transaction. This is most often because the metadata the two packagers are working with were taken at a different time (DNF has a notoriously looser schedule on metadata updates to save time and bandwidth), and sometimes also because the depsolvers inside are designed to take a different course of action when encountering specific update scenario.
The bottom line is: unless a real update problem occurs (i.e. DNF refuses to update a package that Yum updates) with the same set of metadata (dnf clean all; yum clean all), this is not an issue.
(This article is an invitation for the regular Fedora users to start using DNF as their main package manager. If you are near Fedora development, read the Development discussions list or visit this blog then the article is not going to reveal much new, sorry.)
Have you ever tried Yum to install or manage your software and got disappointed? Was it ever so slooow? Or have you tried to write a Yum extension, drowned in the API, failed? We have something different to offer now: DNF—the next generation of package management.
DNF is a package manager that was forked from Yum in early 2012 with the goal of building something that looks and feels like Yum from the command line but provides better experience for people interested in writing plugins and extensions for DNF.
The first Fedora where we shipped was F18 the last winter. Many Yum commands were missing and the early adopters got surprised a lot. That is no more the case with the version shipped in F20 (0.4.9) as DNF gets more stable and feature-full, pretty much everything known from Yum works in DNF. Give DNF a chance today, simply by having it installed ('yum install dnf') and from then on replacing the word 'yum' with the word 'dnf' each time you need to do some packaging, e.g.:
dnf install thunderbird
or:
dnf upgrade -y
It is true that DNF will sometimes handle the command lines arguments or the depsolving puzzle or similar things differently. To help the users transition smoothly and know about any possible speed bumps ahead we have a document that sums these things up.
To compensate for your trouble we offer comfort and speed: DNF installs a system timer that makes sure the package metadata are up to date all the time. So a sudden invocation of DNF from shell doesn't take two minutes just to check the remote repositories for package updates but instead starts on the job immediately. We also use a very solid depsolver (developed and used by SUSE) under the hood. The early adopters report great speedups of the depsolving phase and our measurements indicate it treats the memory more economically.
To put our money where our mouth is we use DNF daily to update and modify our systems and haven't had the software installation broken yet. During the autumn we integrated DNF within Anaconda so it is now possible to bootstrap the system without using Yum at all. We listened to the early users and gave them the known Yum goodies like full history support and parallel download.
What's happening in the future? We'll start shipping core DNF plugins soon, they will provide additional features that people miss from Yum but that quite don't belong in the core DNF. Developers should check out our growing API. The Anaconda integration needs some fixes and polishing. And then there's the feedback you're going to give us after trying out DNF in F20 that we have to process and implement. The master plan of course is to give people everything they want from Yum and much more in DNF, and when Fedora 22 comes pronounce Yum dead and call DNF the new Yum!
In case you've been trying to find our coding standard and overall recommendations on how to hack on DNF, there's DNF Hacking wiki page.
What's new? Plenty! We finally support plugins. The interface looks poor so far as we rushed to get the release out, but it already can be used to implement a big HALT when a non-root tries to run an RPMDB-changing command (like dnf upgrade).
Doing history rollback is supported again. So is printing out just the installed packages selected by user. Can come in handy when moving to Fedora 20, no?
Another addition we were often asked for was a way to support replacing a package with a conflicting package without disturbing any packages depending on these. This DNF version supplies the --allowerasing switch to facilitate just that.
On top of that a couple of bugs and a couple of API extensions. The release notes mention them all.