David Lehman (dlehman@redhat.com) said:
In theory, what we need is two new meta-group types: variant (aka spin) and addon. Each is a set of groups. You can only have one variant selected or installed at any given time. Each variant defines a set of addons, of which any number may be selected/installed. Regular groups and packages are only exposed via kickstart, if at all.
Once we have the groups set up and accompanying kickstart support, the spins should end up being exactly the same package set as you'd get by choosing the same variant+addons in the anaconda software selection ui. The addition of meta-packages and/or kickstart script snippets (perhaps per variant?) could bridge the gap so that the spins end up identical to the corresponding anaconda variant/addon selections.
How does this fit with your proposal and your concerns?
I can see this working. Initial concerns:
- Would we need to drive the variants and add-ons into first class objects in yum as well (such that, if intstalled, they're marked on the system in some way (yumdb, etc.), and that they can be installed post-install, etc?) The simplest solution is add these as additional sections in the comps file, and parse them with yum's comps module - the question is whether this info is used in yum itself outside of that, or if it's left for higher-level tools.
- In RHEL, due to fun with entitlements & certs, add-ons are segmented as separate repos. Your proposal doesn't obviously prevent this, but I think we need to explicitly keep that working.
Bill