Monthly Archives: April 2014

DNF 0.5.0 Released

We’re glad to announce that 0.5.0 is being released into the wild today. There is twenty bugzillas fixed as documented in the 0.5.0 release notes.

As my post from earlier today explains, the focal point of changes in this release was groups and how to approach them sanely. Then there is some niceties like improved documentation, fixed resource leaks and one feature that hopefully many everyday users will find useful: the --refresh option that forces expiration of all repos, thus ensuring given operation runs with the latest & greatest metadata (just don’t come back complaining it takes time).

The API was extended massively, but nothing is dropped or deprecated in 0.5.0.

In Fedora, we are going to wait if the Rawhide build users do not report any critical problems with the build before attempting to get 0.5.x builds into F20.

How Groups Are Handled in Modern-day DNF

Probably ever since comps.xml was invented, and putting aside its undeniable usefulness for the installer users who could pick and choose groups of packages with a few clicks, the exact semantics of operations like yum group install "some group" and yum group remove "some group", or even yum group upgrade "some group" has been either not useful (the pre-groups-as-objects era) or not clear (the post-groups-as-objects era). Our hope is that the upcoming implementation of groups-as-objects in DNF 0.5.0, with the accompanying documentation in DNF manual as well as this blog post will bring an end to that. I am not going to go into details of different package membership types or categories and environments. These concepts are flawed and their chances of surviving into next few years worth of Fedora releases are mediocre or less.

First are foremost: group operations exist to simplify admin’s life by letting him operate arbitrarily large sets of packages with simple commands. While they do not interfere with other DNF commands, to take maximum value out of them, one should install the system using Anaconda with DNF backend and then manage software using the group command as much as possible. The groups-as-objects DNF remembers what groups were installed and what packages were installed as their parts, so installing some packages manually with the install command hinders DNF’s ability to deduce what is really meant to be installed as a part of a group.

To show some examples:

dnf group install "some group"

goes ahead and looks what packages “some group” contains. If they are A, B and C and C is already installed, DNF installs A and B and remembers that “some group” is installed now. If the next day the admin decides he no longer needs “some group”, then:

dnf group remove "some group"

removes A and B again but leaves C intact. In this case, DNF knows that C does not come from any one group but rather was installed on explicit user’s demand or perhaps is a dependency of some other package from earlier. Anyway, DNF won’t remove C in this case. (Let’s disclose it right here that if an intervening transaction added X depending on B, then B and X both get removed now. The solver should be smarter than that but a) we’re not quite there yet b) this is consistent with the rest of DNF operation where “last in wins”.). If an intervening operation added another B-containing group then group remove "some group" wouldn’t remove B either, so to keep it installed for the other group.

But removal of groups is perhaps not so interesting. What is interesting is keeping the software installed. If, after some time, the distribution release engineering decides D is now part of “some group”, then

dnf group upgrade "some group"

adds D and upgrades the other packages of the group. Similarly, it can be decided that A is no longer in “some group”, then the upgrade would remove it. Keep calm and trust the comps.

Since DNF remembers what groups are installed and what packages were considered group members at a particular time, it actually does what one would expect when he goes ahead and manually removes B from a system where “some group” is installed and then runs upgrade on “some group”: DNF won’t install it back. And that’s one of the main goals we had when designing the new group-handling system: listen to the admins wishes and maintain them through upgrades as much as other constrains will let us.

Happy grouping.

Maintenance Release: DNF 0.4.20

We’ve been busy pulling things apart on the master branch and taking a longer cycle then usual for the next DNF release, which will be labeled 0.5.0 and will bring more changes than usual this time.

The idea was that 0.4.19 in F20 is solid enough to stay current for some time, but there is a critical bug that several people has run into with dnf history info <id>. That’s why I decided to start the 0.4 branch and stay with it in Fedora Rawhide until 0.5 is ready and in Fedora 20 until 0.5 is stable. The next F20 build is thus 0.4.20, available at all the good repos now.

That is not to say that things are unstable in upstream DNF. Contrary, with more eyes looking and the CI spinning nonstop we’re more stable then ever.