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

[Douglas McClendon]

Jeremy Katz wrote:
> On Sun, 2007-08-12 at 23:13 -0500, Douglas McClendon wrote:
>> I have a few changes I'd like to request to mayflower.  I'd like to get 
>> some feedback before actually laying down the effort of producing patches.
> 
> So from a big high-level point of view, I'd really rather _not_ add lots
> more that people depend on from mayflower.  Having two different
> codebases to handle the initramfs (mayflower + mkinitrd) is incredibly
> painful for having to adapt both for changes in the OS, etc.  

I agree that it would be cool if mayflower got absorbed into mkinitrd 
(or vice versa).  But that seems a litte far off right now, wheras the 
changes I presented were all very small, and only served to structure 
mayflower in a better way, which I imagine would make it's absorbtion 
into mkinitrd easier, not harder.  I.e.

#1 - this can be used to replace all that ugly cp /bin/stuff bin/ with 
an elegant FILES= syntax in the existing mayflower.conf

#2 - as you agreed, just makes sense to not hard-code /etc/mayflower.conf

#3 - consider how my reply (--program) would be implemented, i.e. by 
creating scriptlets in variables that get conditionally expanded in the 
inline init creation.  This sort of method of modularizing what gets put 
in the init (think the OLPC specific parts, and everything else), makes 
it much more elegant.



> 
> And given that overall mkinitrd "does more", I think it's going to be
> better to get the live image specific stuff integrated into mkinitrd
> rather than spending a lot of time making mayflower more flexible for
> the sake of flexibility.
> 
> But to comment on the concepts...
> 
>> #1 - mayflower.conf - add PROGRAMS and FILES
> [snip]
>> FILES+= would differ from PROGRAMS, in that the auto shared library 
>> dependency check would not apply to them.  Maybe that doesn't matter, 
>> and you could just have FILES.
> 
> Having two different lists is just asking for people to pick the wrong
> one.  Since I can't think of a real reason that you'd want a binary
> without its deps, just lump them together.

Agreed.

>> #2 - support user specified mayflower.conf location
>> (i.e. not just /etc/mayflower.conf)
> 
> Not terribly against or for this.  Having the ability to specify config
> locations is often useful enough for writing test cases that it's
> worthwhile
> 
>> #3 - optional program, sort of like existing shell cmdline arg
>>
>> Have a cmdline argument of program= and eprogram= which would cause the 
>> specified program to be executed.  program= would happen right after the 
>> current shell, and eprogram would happen right after the current eshell.
> 
> Why not just use init= ?  Other than the fact that doing so is currently
> broken with mayflower (... see above comments about two implementations
> of the same thing :-)

The reason is that I very much like all the mayflower generated init 
stuff that happens up to the point of the existing shell escape.  I.e. 
setting up an environment where bash can run and I can see my devices. 
By specifying my own init, I'd basically be duplicating the mayflower 
init generation code, except with my program= escape point, at which 
point...  hey, I'm back where this proposal started.

-dmc