hierarchical comps groups proposal

[Bill Nottingham]

Jens Petersen (petersen at redhat.com) said: 
> > (I'm not going to contribute actual work on this anyway, but) do we actually
> > need that complexity?
> 
> I am not sure how complex it is. As Ales pointed out
> it might allow us to remove environment groups for example
> so it might actually simplify comps, as well as eliminating some repetitions.
> Note that more modular comps would also be helpful for people
> writing kickstart files for example.
> 
> > > The idea is make yum groups in comps more modular,
> > > ie groups could require other groups not just packages;
> > > at this time I don't think it would require any GUI changes.
> 
> > So the proposal is not to show them as really hierarchical, and not to add
> > any structurally new user-visible features[1] just to avoid repetition in
> > the comps file?
> 
> To me current comps is quite messy because everything has to be "flat"
> which limits its flexibility in various ways.
> But right, *initially* I reckon hierarchical groups need not *require*
> any GUI changes to anaconda, etc.  In the first instance it would be
> about providing greater structure and more fine-grained groups in comps.
> Later these could also be used for more advanced selection of groups
> in the installer and package GUI.

My concern would be how deeply woven the current format is into our tools -
it's yum, PK, DNF, anaconda, and all the tools built on top of it. It's
exposed in kickstart. It's expected to be handled by older versions on
upgrade, or even by mock when constructing arbitrary build roots.

So care would need to be taken to figure out a good way to land this all at
once, in a way that's backwards compatible enough to not break other things.

Bill