Monthly Archives: October 2013

DNF 0.4.6 Released

0.4.6 brings two new major features and much more. Firstly, a series of patches revives the history undo command, so transactions can be reverted now. In essence undoing a transaction is performing its inverse transaction. There is a couple of things worth mentioning to this: if one package replaced another in the original transaction than to perform the undo the original package needs to be available in a repository somewhere and also if RPM fails to validate the inverse transaction (typically because of dependency errors), then that’s it, DNF will not force it. So keep your RPMDB consistent and healthy at all times and if a package is missing mail your favorite Fedora infra admin about the way we remove superseded packages from the update repos.

Secondy, DNF will now limit the number of installed kernels and installonly packages in general to the number specified by installonly_limit in the config. People who got bitten by having 15 kernels installed and running out of space on /boot shall suffer no more.

There are vast internal changes to dnf.cli, the subpackge that provides CLI in DNF. In particular, it is now better separated from the core which in turns allows simplification of some unit tests and makes (the up and coming) API more reasonable. Oh and saves us a a lot of “WTF is that?” from new upstream contributors.

The hawkey library used against DNF from with this versions uses a recent RPMDB
loading optimization in libsolv
that shortens DNF startup by seconds when the cached RPMDB is invalid. This generally applies in every DNF run after the RPMDB has changed (for instance the previous DNF run did an installation). Measured on a box with a mid-range SSD and all around average specs, the RPMDB load time itself drops from 1900 ms to about 150 ms. Not bad, but all the credit for this really goes to Michael Schroeder of the SUSE/libsolv fame.

We have also added further fixes to support Python 3 and enabled librepo’s
fastestmirror caching optimization
so the slowdown some of us have observed after enabling fastestmirror few releases back should get reduced again.

Please also see the 0.4.6 release notes for a complete list of bugs fixed.

Anaconda Payload Preview

The Anaconda to be shipped with Fedora 20 includes experimental DNF Payload to install packages for your system via DNF instead of Yum. This is an important proof of concept for DNF and a validation of our approach. If you’d like to try the payload out with Fedora 20 Beta, just add the “dnf” parameter to the kernel boot line when booting the installation media. Any bugs found, report them to the Red Hat bugzilla against Anaconda. They will not be able to block the F20 release, but, if valid, will be dealt with eventually.

The payload downloads all packages in parallel. It is thus going to be faster for network installations and the quick measurements I did yesterday on a KVM machine (hosted on a regular i7 laptop with SSD) yielded some encouraging results. Automatic kickstart installation, only the @Core group included, time taken from the boot of the installation image to the moment when Anaconda screen that says ‘Complete’ appears):

  • yum: 7min 54s
  • DNF: 4min 19s

The Payload can currently be used only to install relatively low amount of packages as it downloads the .rpms to the installation ramdisk. The downloading and displaying the download progress is one area that still needs work.

DNF 0.4.4 Released

Jan Šilhan finished and got merged his initial patch to support Python 3 in DNF last week so we released a new version yesterday. The 0.4.4 also includes a couple of tweaks to the slowly emerging API and a fix to the bug where DNF ignores the file conflicts and naturally finishes the transaction set.

About Python 3: do not expect dnf install package and similar to run from CLI just yet, we are still waiting for F20 GA for all the components involved to be available for Py3. Many thanks to Tim Lauridsen for quickly porting python-iniparse. The plan now is to give Py3 and DNF heavy testing during the Fedora 21 development cycle and eventually switch to it as the default. Then drop Python 2 support as soon as Anaconda is running in Python 3.

Read the full release notes to dnf-0.4.4.

DNF 0.4.3 Released

Because the Too many open files bug came back and up until now DNF had to be released in lockstep with librepo, the new build is coming out earlier than expected.

0.4.3 also brings back support for group info and group remove commands. The official release notes have been published.

Let’s say a few words about using a precise version Requires: in an RPM spec, in Fedora. DNF currently uses few libraries that are new, that are developing violently and that unfortunately change their API now and then. I maintain one of them (hawkey) and know what it is like a for a new lib to commit to a certain API from the start and so didn’t require that from libcomps nor librepo. To have some control however over what version DNF is using, because after all if the API changes and new library is released into Fedora repositories, the users will experience and report the strangest bugs, the spec contained lines like:

Requires: python-librepo = 0.1.2

The deal was that the librepo maintainer (and others) would let me know when he’s about to do a new Fedora build, we’d update DNF to use the API at the desired librepo version and do a build in a lock-step with librepo.

There are several drawbacks to this which together render the whole approach unworkable. Most of them have to do with buildroots in a branched Fedora, where only packages tagged stable or put into a “buildroot override” can be built against. This slows down the builds as e.g. putting a new librepo into the buildroot override does not happen instantly.

Even worse can be the situation in the rawhide Fedora. If a packager of a required library suddenly decides to make a new build without cooperating with the DNF team, the koji builder won’t stop him. It just considers the last built version the current and starts sending emails around that DNF has broken dependencies as it depends on a version that is no longer current. And we receive bugs.

The new arrangement is the same as for most packages: have some minimal dependency version and require a version greater or equal that. While it is promising to make our life easier, it will occasionally break things for the user. In part, this exposes how imperfect the current Fedora build and update policies are, and in part it supports two concepts that we so often fight against in packaging: support for multiple parallel versions in a distribution and app bundling.