On Thu, Mar 29, 2012 at 7:18 PM, Chris Lumens <clumens@redhat.com> wrote:
> How is that possible to implement with a:
> 1. Show GUI, write kickstart.
> 2. Process kickstart.
> design?

We're not literally going to have one program that you use to construct
a kickstart file, write the file out, and then spawn a separate program
do to the processing of.  We are using kickstart as the data store
internally (via pykickstart) and having one program operate on it.  The
only writing will be towards the end of installation, where we spit out
/root/anaconda-ks.cfg.

A lot of these tasks like figuring out authentication information and
adding extra users can be prompted for while filesystems are being
created, then actually take effect and augment the ksdata after packages
are laid down.  They will be reflected in the final anaconda-ks.cfg.
Some other tasks may not map to existing kickstart at all (yet).

- Chris

If we go for doing something like that, is there any reason to keep firstboot around? Couldn't we stuff the actions done in firstboot into anaconda with this newer asynch design?