On Thu, Mar 29, 2012 at 7:18 PM, Chris Lumens <clum...@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 > -- > devel mailing list > devel@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/devel > 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?
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
