[Fedora-spins] Packaging & installation

[Bill Nottingham]

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