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

[Sven Luther <sven.luther@wanadoo.fr>]

On Thu, Oct 06, 2005 at 11:57:16AM -0500, Manoj Srivastava wrote:
> 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.

Indeed, there should be some (to be determined) solution for those situations.

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

Yes, altough just parsing kernel-img.conf is not enough, since we need to have
per-version choices of those. using /etc/kernel/config/<version> would be one
possibility, put doesn't adapt well to more flexible things like :

  1) different stuff for 2.4 and 2.6 kernels.

  2) different stuff for kernels > 2.6.12.

maybe some format allowing to add versioned constraints to the main config
file ? Not sure how clean that would be, imagine :

mkimage = mkinitrd
mkimage [$version > 2.6.12] = yaird

Or something thus ? 

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

Well, see above.

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

maybe simply : /etc/kernel/config/<version> ? 

> >> 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

Indeed, which is why i advocate moving that info into the kernel rules. Or
even in a per-arch kernel-knowledge-base 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)

Indeed, but i guess you can keep it with using some modular schema like
discussed above, which would default to the standard case and allow us to add
more advanced solution for newer official kernels and such.

Friendly,

Sven Luther