This is just throwing out ideas. I see the dilemma about comps. If someone see's a way around it, then it would be nice to use comps, but no-one does, then yes, just go with something new and simple. Another argument for the simple lists, is that our users would be able to understand them better (hopefully). Right now when you try to explain 'hiden' or levels, most don't care about that. If we are going with a simple list idea, it would still be nice to have 'groups' within 'groups'. So that if I wanted to make my own group called 'troy' it wouldn't have to list everything, but could just call the kde group, and the gnome group, and the devel group. About the multiple server groups problem, here's a couple ideas. (just brainstorming) You could add a grouppolicy to the conf file. Though this wouldn't necessarily take care of all the problems, because someone might want to use all the groups on serverB, except for this one group on serverA. You could have the group policy be whatever the pkgpolicy is. (newest or last) You could have an option so that if you do a groupinstall or groupupgrade you could do something like 'yum groupinstall mygroup[serverA]' or 'yum groupinstall --server serverA mygroup'. Basically something where the user could tell yum what server they want, and if they don't specify a server, then they get whatever is default. On a related note, it would be nice to have a command that lists the items in a group, or maybe that would be what grouplist would be. 'yum grouplist' would list all the groups, while 'yum grouplist mygroup' would list all of the packages in mygroup. Troy -- __________________________________________________ Troy Dawson dawson@xxxxxxxx (630)840-6468 Fermilab ComputingDivision/OSS CSI Group __________________________________________________
