Re: Kernel-package, fix version 2 ...
On Sat, Oct 22, 2005 at 04:16:00PM +0200, Sven Luther wrote:
> On Sat, Oct 22, 2005 at 01:41:32PM +0200, Erik van Konijnenburg wrote:
> > On Sat, Oct 22, 2005 at 08:36:50AM +0200, Sven Luther wrote:
> > > In any case, i think the best idea would no more be to make a hard choice, but
> > > maybe use some kind of heuristic, or even make it configurable at package
> > > build time, so that it can be overiden. I need to think about this a bit more.
> > >
> > > Coments are welcome (and anyone not caring to reply, kind of loses the right
> > > to complain afterward, particularly if they claim i am not communicating on
> > > this).
> > Sounds workable, and it's something you can build in the kernel install script
> > without need for support from initrd/initramfs builders; I could live with that :-)
> > Perhaps we can simplify this further:
> > * have list of alteratives built into the kernel installer,
> > * allow ramdisk= in an /etc file to override this,
> > * run them all,
> > * and the first one that has exit status 0 and a non-empty image as output wins.
> I kind of dislike this let's try everything in turn, in particular i am afraid
> of a tool which claim success and produce a broken image, and such. Also it
> may considerably slow down installs.
Yep, tools that produce an incorrect exit status break this approach.
The slowdown could be manageable if the most flexible tool goes in front
of the list.
> Also the postinsts are in perl, and my perl is not all that good, so i dislike
> complex modifications of this kind.
Strong argument: you're the one doing the actual coding here,
so it's important you feel happy with the approach.
> > The nice bit about this is that it should survive with odd version
> > requirements like: initrd-tools works for 2.6.12, but not in combination with lvm.
> Yep, but will it report failure ?
If at the end of the list all tools had non-zero exit status, you could produce a message:
"could not produce an image, and these are tools I tried ...".
> > The only requirement is that generators do not lie about success in their exit
> > status, but no flags are needed.
> Yeah, i still feel that the guided approach is better, but hey.
Again, you're the one building it; the guided approach works & you're comfortable
with it, so lets go that way.