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.
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.
Seven days later, we're back with another release. This one only gives a couple of bugfixes, mainly the groups traceback that stopped 0.4.18 from making F20 updates.
Let's hope this release is less buggy. It also ships our own gettext .mo files so translations will work as they are supposed to. We're on transifex too.
Release notes have been published and Fedora builds are being cooked right now.
(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.
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.