DNF 0.5.4 Released

0.5.4 has been released today.

A major improvement in this release is the repo priorities config option. With it the admin can enforce packages of a certain repository to take precedence over other ones during an upgrade even when the prioritized packages have lower version. The original DNF bug is here, the functionality is known from Yum Utils as “priority plugin”.

The stream of Unicode/encoding problems people run into is not ending unfortunately. Rather critical problem has been fixed now. We look forward to fully move to Python 3, and if you want to help the cause please gently say so in the EPEL7 python3 bugzilla.

Fedorians, note that you can start experimenting with Python 3 from CLI with this release, as the python3-dnf now ships /usr/bin/dnf-3. Note that the binary is experimental and will be removed once Python 3 becomes the default interpreter for the main DNF package, hence it is not and will not be documented anywhere.

Release notes are published at the usual spot.

DNF 0.5.3 and Core DNF Plugins 0.1.1 Released

Hello, after one month the team is releasing a new version of DNF and its core plugins. We’re still getting reports of problems with Unicode and translations and the current release does away with many of them.

People on older and special networks will appreciate addition of the -4 CLI switch to force IPv4 DNS resolving.

Besides that, the focus in DNF was on extending the API to enable implementation of the popularly demanded protected_packages plugin. The plugin works by checking a resolved transaction and stopping it immediately in cases where an explicitly protected package or the running kernel should get removed.

See also:

Happy packaging.

Core DNF Plugins 0.1.0 Released

It looks like the Core Plugins have stabilized over the last few months so I decided it’s time to give them more independent releases with proper release notes. It is my pleasure to announce 0.1.0 today adding dnf repoquery plugin and a bugfix to dnf builddep.

If you’re not familiar with DNF Core Plugins, make sure to check out our new documentation too, perhaps there are plugins you miss and don’t know that exist. The name of the package in Fedora is still dnf-plugins-core.

DNF 0.5.2 Released

DNF 0.5.2 is being released today. Our biggest hope from this release is that the Unicode-related crashes some people were getting are resolved.

One thing we’ve been repeatedly asked for is autoremove. Delivered in 0.5.2, the command looks at the packages installed, and the reasons why they were installed. Those that were explicitly installed by the user are left untouched. Those that were installed as a dependencies are left untouched if they are needed by some of the packages in the first group, else they are removed. This way only the packages that the user wants and their dependencies remain on the system. Also see the documentation. Note that those people who exclusively use DNF for their packaging operations and have clean_requirements_on_remove enabled will only get empty transactions from autoremove. The rest can benefit.

Release notes have been published, Fedora 20 update is coming shortly.

New core plugins are also out (0.0.8) today. It now includes a download plugin (when you just want to get an .rpm file on your filesystem but are not particularly interested in installing it) and manpage documentation.

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.