On 03/29/2012 10:15 PM, Conan Kudo (ニール・ゴンパ) wrote:
On Thu, Mar 29, 2012 at 7:18 PM, Chris Lumens <clumens@xxxxxxxxxx
<mailto:clumens@xxxxxxxxxx>> 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@xxxxxxxxxxxxxxxxxxxxxxx <mailto:devel@xxxxxxxxxxxxxxxxxxxxxxx>
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?
Well, there are some reasons on each side there, and it certainly merits further
discussion.
Personally, I've got some skepticism about running firstboot-style plugins in
the installer. For those that need that (and they are out there), it's a whole
lot easier to put things like that in the packageset and have them run at
firstboot than to get them into the running install image. But if we decide it's
worth it, that's probably a problem we could engineer around, too.
--
Peter
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
