The goal is now very simple.  Two labels:

* One label has a binary import of all the packages in Fedora.  All.
 Even the trademark packages.  This is a mirror of Fedora, and the
 fact that we're adding Conary metadata is not conceptually different
 from a yum mirror with yum metadat; it just happens that Conary
 metadata is much richer.  That metadata consists, essentially, of
 Conary packages encapsulating the RPMs, and groups which tie those
 sets of Conary packages together to give chronology.  The groups
 that tie those packages together should be structured like the rPath
 encapsulated imports -- a toplevel group that contains two subgroups,
 one of which represents a base install and the other of which references
 all the packages.

* Conary and any necessary deps that aren't in Fedora proper on a
 separate label, and groups that tie together those packages in
 sets.

We do not need to have Development/Release stages, at least for the
Fedora mirror label (we should keep stages for the tools label).
After bootstrapping the import, we can import packages; they won't
show up in normal use with rBuild until we have a successful group
cook referencing the packages, but they'll be available for adopting
an existing system as soon as they are imported.

Anyway, those two main things are enough to be able to install a
Fedora system with anaconda, add Conary to it, and then wrap
Conary management around the Fedora system that was "adopted".