Re: Final resolution for the kernel-package ramdisk handling project ...

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

On Sun, Oct 23, 2005 at 07:57:09PM +0200, Jonas Smedegaard wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Sun, 23 Oct 2005 18:41:11 +0200
> Sven Luther <sven.luther@wanadoo.fr> wrote:
> 
> >   4) In the default case (no ramdisk= field), or in case of a list of
> > tools, we first check for the existence of the tools, and then check
> > if they support the --supported-* option and also claim to support
> > the user configuration (host ans target version). It will eliminate
> > all the tools not conforming to this, and chose the first of the
> > remaining ones, and fail if no tools is left.
> 
> Not quite. What we agreed on was Vorlon's psudocode[1], except the use
> of debconf.
> 
> Your description above ignores legacy ramdisk tools when part of a
> list[2]. We agreed on including legacy tools even when not explicitly
> set in /etc/kernel-kpg.conf.

No, how do you expect to make this happen. The default is the multi-entries
thingy, and it will search for them in turn. The default case being previously
using initrd-tools, which is still the default, and supports the --supported-*
scheme, so it will work in all case.

If we take the current approach and ignore this, and decide to give
initrd-tools a try even though it is supposed not to work, we will end up
using initrd-tools always.

We have some time until the etch release to fine-tune this though.

> With this one exception, I agree with you, and thank you for the fine
> announcement.

Hehe.

> [1] http://minbar.dodds.net/~vorlon/k-p-pseudocode
> 
> [2] Even though all three major ramdisk tools (initrd-tools,
> initramfs-tools and yaird) now supports the new query mode, debian
> contains other ramdisk tools - and users may rely on other tools as
> well. Some may do so by redirecting to another tool
> using /etc/kernel-kpg.cfg which is irrelevant for this nitpicking, but

kernel-img.conf :)

> others may use dpkg-divert with an mkinitrd wrapper.

Indeed. My main problem with this is that we don't know upto now to
distinguish between the tool returning 1 because it does not support the
config, or returning 1 because it doesn't know about the --supported scheme.

And as you said, we have no guarantee that if we check for 2, we won't break
some other use of it by some random tool out there.

This will do for now, but once we agree to return 2, we can modify this
further, what do you think.

Friendly,

Sven Luther