Log in

Understanding groups in yum - James Antill

Aug. 7th, 2008

11:40 pm - Understanding groups in yum

Previous Entry Share Next Entry

Every now and again someone will will ask a question about groups in yum that amounts to:

If I do "groupinstall xyz" and then I do "groupremove xyz" why do I not end up where I started.

The main problem here is thinking of "groups" as objects that are installed and/or removed by yum, in fact currently the only way yum stores data on your computer is:

...and given that rpm only installs pacakges and that doesn't include extra package data like which "groups" the package is in, it's easy to realize that yum cannot perform the groupinstall/groupremove operations using that model (even if that seems like the "correct" thing to do).

What really happens then?

The simple way of thinking about it is that each group is a collection of package names, and on a groupinstall/groupremove yum collects all the package names in the group and tries to install each one (or remove each one). This works exactly as if you had run groupinfo, put all the names in a text file and run that through the "yum shell" command, there is very little magic in how this works and is a simple model (once you forget the "obvious" model as above). One way of thinking about it is that groups are more like "tags" in del.icio.us or livejournal etc.

There is a little more complication in that each group actually has four lists of package names, but groupinfo also displays the different lists in the groups so again the model is the same as the text file example.

So as you might expect from the above: if you have x, y and z installed; then groupinstall "foo" which contains a, b and y; then groupremove "foo" -- you'll end up with x and z.

But what about if we just add some magic?

The next question people ask (usually without fully understanding the above) is something like ok so groupremove will remove things I had installed before a groupinstall ... but if I do "groupinstall GRP1 GRP2" and then "groupremove GRP1" it should be easy to just keep any packages in GRP1 and GRP2, no?

And this does sound easy to implement, just only remove files that are only in GRP1. Except that packages can be in any number of groups. So consider the first example again, the question implicitly assumes that "x" getting remove should be based on whether "x" happens to be in another group or not. This little bit of magic in yum would then become very magic for the user, and it would be very hard to tell what a groupremove command is going to do.

But, but, usability! Do what the users expect!

In my opinion most of the problem here is with the way applications present the concept of "group" to the user, including yum itself (although noone would like the new command name for the cmd line client). GUI package management applications that use yum group definitions shouldn't present the user with an option to "install group X" instead the operation should be presented to the user as "install/remove all packages in group X" with the option to (de)select only parts of the list.

The other thing to do is for people to fix their groups so that "common" applications aren't in weird groups, so that groupremove on those groups is a useful operation again.

Cool, groups are interesting but I can't control the groups from Fedora/etc.

Actually you can, the full list of groups in yum is taken from all the enabled repositories. This means that if you create an empty repository with a group file in it, you can create your own groups! Just like tagging your own URLs in del.icio.us

Tags: , ,


Date:August 8th, 2008 02:16 am (UTC)

More metadata could help

The point is doing what the user expect, so if YUM could inform the rpm database (or maybe have it's own DB) that a particular package was installed as a result of installing a group the removal of this group would remove only the packages that were installed in the original operation.
(Reply) (Thread)
[User Picture]
Date:August 8th, 2008 05:01 pm (UTC)

Re: More metadata could help


True, we are planning on exploring changing the model when we can store extra data in the rpmdb. I'm not 100% sure it will be a good idea, due to the corner cases (and what happens if/when group membership changes) ... but we'll certainly try it and see what it looks like.

We have also written code to store data directly in yum, but Fedora is against it as that would then force any other package managers to either repeat the data or talk to yum. The idea being if everyone could just talk to rpm that would be much better (and there would be only one real DB anyone needs to care about).

But if that change happens I still think it'll be better to present the user with "this group contains these pkgs, install some/all of them?" rather than just the "install group [X]" type option ... and also to remove core pkgs from weird groups.

The complete list of rpmdb pieces we want are roughly: 1) what repo. was X installed from 2) was it installed directly, via. a group or via. a dep. 3) what yum groups was it in. Other devel priorities are:

(Reply) (Parent) (Thread)
Date:August 8th, 2008 05:56 pm (UTC)

Re: More metadata could help

I agree, maybe groups should not have a installed state at all, they function only as a filter, this would naturally cut all the corner cases. If a user want he can install all the packages, but the operation of removing a group is, or at least should, not be well defined.
(Reply) (Parent) (Thread)
Date:October 16th, 2008 08:23 am (UTC)

I don't like Yum groups


Well, I just want to add my own opinion. I really don't like the current package group handling of yum. If all yum intends to store is via rpm then why not do like Debian and make groups empty packages with lots of dependencies instead of being some special magic.

The possible downside is when you want to remove something which came via a group but that in turn removes the whole group. So maybe a Depends is not the correct thing to do, but a Recommends or Suggests (in case RPM supports these). Something that installs the package in question, keeps it from automatic removal of auto-installed packages (hypothetical, as yum currently can't do it), but allows explicit manual removal.

Other than this, yes, even more special magic can be added to RPM and Yum but is that really a good idea?

(Reply) (Thread)
Date:January 23rd, 2010 10:23 am (UTC)

Even bigger problem...

The biggest problem I see with yum and groups is the way how yum determines if a group is installed or not: Ether all mandatory packages need to be installed or - if there are no mandatory packages in that group - at least one optional package. It's hard to follow this logic and impossible to visualize this in a UI. This means that it's impossible to install a group with gnome-packagekit because it is already shown as installed.

Say I just have the core components (mandatory packages) of a group installed and want to get the default package selection I would get with yum groupinstall. How would I do this graphically? Impossible!
(Reply) (Thread)
[User Picture]
Date:January 25th, 2010 05:36 pm (UTC)

Re: Even bigger problem...

I assume you are talking about gpk-applications's "package collections" UI. But that's not yum's problem, IMO. The problem there is PK designing the UI for the LCD, which is group == single fixed collection of packages ... which isn't what the word "group" has ever meant to yum or Fedora and I seriously doubt it's what any user wants.

The newer gpk-app's also have the real groups UI on Fedora, and that's much better (giving you a browsable tree) ... but it still doesn't map very well to what Fedora/yum provide, and again I have a hard time blaming anything but PK for that failed mapping.

I also don't see how the yum side could make PK's life easier, even if we implemented some of the proposals to make groups "easier" (like making groups real objects, so they update etc.) ... that would require even more work on the PK side to represent that. About the only thing we could do is regress groups to the state of meta-packages, which is what Debian/Ubuntu uses.
(Reply) (Parent) (Thread)