[Fedora-livecd-list] RFC- mayflower flexibility enhancements

[Jeremy Katz]

On Mon, 2007-08-13 at 01:07 -0500, Douglas McClendon wrote:
> Tim Wood wrote:
>   Then (I believe) someone could
> > have a kickstart and a config file to handle everything.  Then Revisor 
> > would need one additional field to select the path to this config 
> > file.   A couple of advantages:
> > * A sample kickstart and a sample config with lots of comments and all 
> > the options plus a basic tutorial would be all the documentation many 
> > people would need
> > * It would make it much simpler to return to a project months later and 
> > tweak/tune/use it (find 2 files you left in /etc/revisor/... vs. files 
> > there, notes somewhere else and maybe some custom bash code somewhere else)
>
> What you are getting at here, is really the crux of the debate I had 
> with jeremy over the addsdir/addidir patch, and the ideal of 
> reproducability from a _single_ config file.
> 
> The basic problem, which I think you solved with your outline above, is 
> that kickstart is simply not appropriate to be the one _single_ config 
> file for a livecd project.  The two examples that immediately spring to 
> mind are

People are caught up, though, on "you can't add anything to kickstart".
Which is a patently false statement.  Also, the idea is that we're also
moving pungi also over to use the kickstart syntax (+parser).  That way,
you have _one_ config file that can be used for any of the following:
1) Create a live image
2) Create an installable tree
3) Install from an everything type tree

Which starts to be pretty flexible.  For some of the things like initial
config, etc -- well, we're starting to want to let that be specified
when creating an installable tree so that you can create an installable
tree with a certain set of default config stuff that anaconda listens
to.

> 1) files added to the iso filesystem.  E.g. like ubuntu's inclusion of 
> the windows firefox installer.  Or a generic web page to be viewed under 
> windows when the livecd is inserted in a windows system.
>
> 1A) have some truly magic livecd kickstart command to add files to the 
> isodir.  This command would be silently ignored in the non-livecd case 
> (or perhaps files copied to /iso or some arbitrary directory in a 
> non-livecd kickstart invocation).

It's definitely going to be okay if there are things that livecd-creator
+ pungi use when they're doing things that the normal install case
ignores.  Much like today, livecd-creator ignores a few things that
aren't relevant to it.

> 2) the persistence feature.
> 2A) and this is rather key- put the mayflower invocation in the %post of 
> the kickstart.  Perhaps even enclose it in a conditional, based on some 
> variable that only gets defined in the livecd case.  

I'm not sure how persistence really requires anything in the config.
There's not any reason why you wouldn't want your live image to be
_capable_ of persistence.  You may configure it to not enable it by
default, but that's a different story (and from our earlier discussion,
a boot arg is probably sufficient for this and with the handling of the
bootloader argument that I was pointing kanarip to last week, this just
falls out, voila! :-)

> Then perhaps even 
> merge the livecd-creator code back into anaconda, ala the old kadischi 
> anaconda rootpath livecd creation facility.  (yes Jeremy, I'm trying to 
> give you nightmares ;)

FWIW, I keep coming back here -- the amount of code that we're basically
copying and pasting from anaconda is a little depressing.  And
especially with markmc's patches to sort of abstract out the "what's
being installed to", we get even closer.  And by cleaning up anaconda
and moving over to using it, we get a UI for "free".  I don't know what
the long-term answer here is :-/

Jeremy