David Lehman (dlehman(a)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