[Fedora-spins] Packaging & installation

[Bill Nottingham]

Prompted by David Lehman's patch set, I wanted to discuss how we're
building what we're installing in Fedora and RHEL, and how we might need to
represent that both in the media and in the UI.

What we've got now exposed at the lowest level (yum/kickstart) and supported
as first-level objects throughout the system:
1. packages
2. groups (of packages)
3. repos (which contain group lists, and packages)

What we additionally expose only in anaconda, and lose post-install:
4. tasks in install classes (lists of groups)

What we expose in Fedora:
5. spins (live ISO via kickstart file)
6. 'the install DVD' (a package set via a kickstart file)

What we expose in RHEL:
7. variants (essentially, a spin that's a package set instead of a live ISO)
8. add-ons (repos, with groups, that apply to specific variants)

All of these use the comps file, which is a list of groups.

Now, as we rework anaconda's UI (and backend, per dlehman's patches), we
need to make sure not to break everything horribly.

In Fedora, spins and the install DVD are driven off of kickstart files. This
was done because it's the only thing pungi and livecd-creator supports, and
because each spin/install DVD is a distinct object that can have its own
kickstart. Anaconda doesn't need to worry about separately consuming them,
as there's only one repo to ever pull from, and the spins are live images.

In RHEL, variants and add-ons are driven off of a different set of files,
for assorted historical reasons. Kickstart files don't directly work here
because they don't allow you to define intermediate objects (add-ons) that
are presented in the installer. Anaconda processes variants and add-ons via
code that reads .treeinfo.

PROPOSAL GIVEN THE NEW UI

For reference, the proposed new UI is at:
	http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Live%20Prototypes/07-software.svg

As you'll notice, it contains something that looks like a spin or variant on
the left, and things that could be considered 'add-ons' on the right. These
apply to the choices on the left.

This would seem to fit nicely into the variants + add-ons model that RHEL
uses. However, there are a couple of problems:

- The code that parses the variants/add-on information and creates the
  appropriate .treeinfo bits does not exist in Fedora

This is obviously a simple matter of not-so-simple code.

- It requires creating a separate set of metadata (the variants file) that
  does not currently exist.

This is relatively trivial.

- It can cause skew between the live and not-live spins if this variants file
  falls out of sync with the kickstarts in spin-kickstarts.

This is ugly - how can we get these to use a single set of data?
Unfortunately, kickstart's %packages model doesn't give us an easy way to
define a variant and its add-ons in a kickstart file. Ideas?

Bill