All posts by Aleš Kozumplík

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.

Copr Plugin

(contributed by Miroslav Suchý)

New dnf-plugins-core introduces new copr plugin.

You can list projects of some user:

  # dnf copr list bkabrda
  ==================== List of bkabrda coprs =====================
  bkabrda/python27rebuild : Collection with Python 2.7 for EPEL 6
                          : (currently just for testing).
  bkabrda/python-3.4 : Testing repository for Python 3.4 that is
                     : supposed to go to F21. 

We have plan for generic search function as well, but it will land in some future version.

You can easily enable some project:

 # dnf copr enable bkabrda/python-3.4 fedora-20-x86_64

 You are going to enable Copr repository. Please note that this repository is not
 part of Fedora distribution and may have various quality. Fedora distribution
 have no power over this repository and can not enforce some quality or security
 level.

 Please do not file bug reports about this packages in Fedora Bugzilla.
 In case of problems you should contact owner of this repository.

 Do you want to continue? [y/N]: y 
 Repository successfully enabled.

You can even omit last argument and it will be guessed. But currently there is know bug, which will
be fixed in next release, therefore you need to specify chroot.
This command will download repo file and save it as /etc/yum.repos.d/_copr_bkabrda-python-3.4.repo

You can disable project:

 # dnf copr disable bkabrda/python-3.4 
 Repository successfully disabled.

which will remove previously downloaded repo file.

DNF 0.4.18 Released

The new release is making its way to Fedora mirrors as I write this. The notes are up.

Distro-syncing specific subsets of packages is finally here. Also 0.4.18 marks the move to objectified groups, something Yum did in 2012. Things might look a bit shaky on the groups front for some time while the precise semantics settles but the basic operations work and support for installing optional packages has been added again. Moreover, the changes provide new API that allows the DNF Anaconda payload to exclude packages from transaction as the user wishes.

API also sees some spring cleaning of parts that we’ve deprecated and kept in the cellar since last December.

On The Name

With the DNF Fedora change published, the feature set closing in on the Yum’s, the number of plugins increasing, the API expanding and the Anaconda integration steadily improving, it is about time to say what is meant by “DNF”, the abbreviation.

To start from the start: Yum originally stood for “Yellowdog Updater Modified”. A colleague of ours thought “hawkey” would be a cool name for a new packaging project, in a random way continuing “Yum” since his yellow-coated pet dog’s name was Hawkey. So that’s how the lib got its name. Now that is near Hawkeye, the M*A*S*H character. So we picked a name expressing some continuation from the previous tool and expressing the new tool is Hawkeye Pierce-dandier by having hawkey embedded in it:

Dandified Yum, “DNF” in short and “dnf” on the command line.[1]

Anybody out there: if you are willing to contribute a Creative Commons logo now that the full name is known, please leave one with your name and email address in the comments and if we find it lovely we’ll get in touch with you.

[1]We also briefly considered calling the forked Yum “BJ”, like Hawkeye’s colleague. That got turned down fast.

DNF 0.4.17 Released

After a week’s development sprint we are back with a new version today.

It was an unfortunate side-effect of the refactorings in 0.4.15 that DNF users of the two last releases sometimes experienced crashes and garbled output during the download phases. This release contains a long list of fixes for those, along with extensions to help us chase similar problems in the future.

There are new API calls in the repo management department and a bug fixed that prevented many from using --cacheonly. Linking to the release notes.

Behind the scenes a lot of work is going into reimplementation of repo-pkgs command from Yum. With repo-pkgs, but also other commands, we are often having a hard time determining which subcommands are legacy and which are used/have use cases. Users’ insights on this problem would be welcome, i.e. we’d be really interested to know what you think is worth dropping and why.