Re: 2.6.13, experimental and 2.6.14-rc ...

[Manoj Srivastava <srivasta@ieee.org>]

On Thu, 6 Oct 2005 18:07:24 +0200, Sven Luther <sven.luther@wanadoo.fr> said: 

>> So, if there is an explicit value, use that, or else fall back
>> through any of mkinitrd, mkinitramfs, or yaird, which happen to be
>> installed.

> What about delegating the initrd creation to the
> /etc/kernel/postinst.d script, and have make-kpkg include such a
> versioned post-inst script into the kernel image ?

        Sure. I guess that would be indistinguishable from the
 kernel-package (and the kernel-image) viewpoint functionally, and
 would allow one to recreate the initial root disk at will, so it is
 better for the end user.

> or alternatively have initramfs or yaird provide those scripts in
> /etc/kernel/postinst.d/, and do the right thing, and kill the stuff
> doing this through /etc/kernel-img.conf for etch ?

        Well, there is the issue of backwards compatibility: if there
 are users who have set up the /etc/kernel-img.conf, one should not
 suddenly have things fail for them.

        I have no objection to transitioning to moving the initrd
 creation out of the monolithic postinst script, and into
 /etc/postinst.d (note: we'll have to also add stuff to the postrm to
 remove these scripts on purge); as long as the transition is smooth
 for the installed base.

        The script, if provided by kernel-package, would also need to
 parse the kernel image configurations, if we are going to allow the
 user to still specify their preference (yaird vs mkinitramfs vs
 mkinitrd vs something else entirely).

> Maybe we could even compliment the scripts in /etc/kernel with a
> per-version configuration file to replace the main one ? the
> make-kpkg provided scripts would parse /etc/kernel/config/kernel.cfg
> and /etc/kernel/config/<version>/kernel.cfg ?

        That is also a doable idea, but of somehwat limited utility
 for the ordinary user (I usually only install a kerel image of a
 particular version only once, so per version configuration files are
 somethings I would never actually get around to setting up).

        I also see no reason to move /etc/kernel-img.conf to
 /etc/kernel/config/kernel.cfg (a lot of churn, and a transition to
 support the old and the new, with little added utility); but I can
 additionally also look at /etc/kernel/config/<version>/kernel.cfg,
 since that would not impact current users.

>> I guess we could add a version specific check into the postinst to
>> default to using yaird or mkinitramfs , if installed, in preference
>> to mkinitrd, though I am usually hesitant to add in version
>> dependencies into kernel-package in general, I could be persuaded
>> that an exception is justified in this case.

> there are archs which should prefer mkinitrd at current state of
> affairs.

        Hmm. I would much rather not have to learn and main per-arch
 idiosyncrasies for kernel-package

> also it would be _very_ cool to do the switch after a major upload.
> just the switch to the newer tools and nothing else.  ubuntu has
> been bitten by this transition.  the user won't recognise that the
> oops is not the kernel fault.  the best plan would be to do it after
> an 2.6.13-1 upload: an 2.6.13-2 with only this change.

        Well, if we can comeup with a reasonably robust mechanism for
 determining what sequence the initrd creation tools should be tried
 in, given a kernel version and an architecture, and something that
 does not need to be maintained (people have had reasonably good
 experience using kernel-package for creating kernel images for
 versions very different from the noes current when that version of
 kernel-package was written, barring bugs in kernel-package -o I would
 not want to lose that version agnostic behaviour by design)

        manoj
-- 
To program anything that is programmable is obsession.
Manoj Srivastava     <srivasta@acm.org>    <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C