Composing custom distros & anaconda

[Bill Nottingham <notting redhat com>]

I was working on composing a custom distro based on Fedora 10,
and I kept running into various minor issues that made the process
not work as well as I'd like. I'm cataloging these here, in case
I'm missing something obvious that I should be doing instead of
what I did.

1) Fedora and RHEL installclasses are directly in anaconda

   To override/remove them, you get to remove them in a custom
   package's %post, and also with a %triggerin on anaconda

2) BETANAG is a constant in anaconda itself

   Again, you get to modify anaconda files in %post/%triggerin

3) anaconda and pungi don't support identical repo definitions

   To override packages in the base repositories, I can set up
   a local repository with packages that obsolete the base repo
   packages, and set cost appropriately (or --exclude/--include.)
   anaconda ignores all of this when building install images,
   causing me to have to go to dirty hacks to not pull in
   packages I don't want.

4) repo editing, and the 'built-in' repos

   Say you're composing a custom distro, with a custom comps file, etc.
   How do you set up the post-install repo files for yum correctly?
   Your choices are:

   1) use the 'upstream' Fedora repos. In which case you have to tell
      it to ignore the group file, and anaconda's built-in repo support &
      repo editing will point to/enable those repos by default
   2) mirror everything into your own custom repos based on what you're
      building with pungi. This is waste of space, and also means that
      you have to make a custom <foo>-release package that points to these
      custom repos... before you even build them. (And if you're doing
      the normal spin, fix, spin, fix cycle, you get to keep
      resyncing/recreating that tree.)

Bill