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

[Douglas McClendon]

Tim Wood wrote:
> The one comment I'd have is would it be possible to feed some (or all) 
> of these options in as a config file? 

Most of my RFC was basically about extending the functionality of the 
mayflower.conf config file.  But currently, as far as livecd-creator 
(and presumably revisor) is concerned, a mayflower.conf is hard-coded.

The question is whether or not there is any reason to expose the 
livecd-creator or revisor user to these sorts of options.

For the selinux enabled on an selinux disabled system, I think this 
should all happen inside livecd creator, and cause things to 'just work' 
(versus now, where it detects the situation, and says 'too bad, you 
can't do this').

For the anaconda rpm build as non-root user, this really has nothing to 
do with livecd-creator or revisor.

And for the vastly trickier idea of livecd-creator as non-root, again, 
there is no aspect that the livecd-creator or revisor user should care 
about, other than having it just work.


  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

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.

2) the persistence feature.

OTOH, here is how I guess I could imagine cramming everything into the 
kickstart-

1) 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).

2) 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.  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 ;)

2 as described (with or without remerge with anaconda) also gives you 
the ability to customize the initramfs (e.g. add persistence and similar 
mayflower optional features) in the %post of the kickstart.

But I want to emphasize to anyone reading this far, that none of this 
really has anything to do with the simple modifications and simple 
functionality enhancements that I was aiming for in the parent RFC. 
This has been a tangent going down rearchitecting the kickstart/config 
file and invocation of livecd-creator.

And actually, given what I described, I kind of like the uglier and 
uglier, but single kickstart solution.  (the other aspects which I've 
complained about in the past, I think I can see workarounds for as well)


-dmc