[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Kernel-package, fix version 2 ...

Hash: SHA1

On Sat, 22 Oct 2005 08:36:50 +0200
Sven Luther <sven.luther@wanadoo.fr> wrote:

>   We now allow the ramdisk to contain either of :
>   1) undefined
>   2) a single field
>   3) a space separated list of fields.
> I will go at this in reverse. In case 3), we do as we do now, namely :
>   prune the scripts which are not exectuable from the list and those
> who do not claim to work in the kernel version ocnfiguration we are
> trying to use, and then use the first one. Notice that currently
> initramfs-tools will probably return usage, and maybe fail, so it
> will be excluded here.


But this is generic, right?

The note about initramfs-tools is just informational, not some "I know
that those stubborn idiots can't provide a working ramdisk image
without accepting my patches, so they will now be left out until
cooperating - HA!" hardcoded into kernel-package or anywhere else,

> In case 2), we modify the thing a bit :
>   If there is only one ramdisk executable, we assume the user knows
> what he does. We thus do the --supported call, and if it returns
> true, we fallback to case 3), while if it is not, we issue a big fat
> warning and ask the user if he really wants to use a tool which
> claims not to be supported and thus potentially break the system,
> reply defaulting to no.

I disagree.

If there is only one ramdisk executable, then that is what the user
wants. Period.

We can add fanciness like spewing out a warning that it might not be
wise, and that warning can vary depending on what we think we know
better than the user (like "hey, stupid fuck - the days of mkinitrd is
over!" and "Wake up, dewd - you really think yaird is ever gonna handle
your EVMS-over-cryptoloop rootfs?"). But warnings only - no questions
and no defaults of ignoring the user choice.

> In case 1) We use some heuristic to chose the tool. This is currently
> a simple conditional on the version, hard-coded in the postinst,
> chosing initrd-tools or yaird (i didn't consider initramfs-tools, as
> it does not build yet on all arches and was having some problems, but
> it may happen in the future, once the transition is done right, and
> we take a decision on the tools, but seriously, given the way the
> initramfs-tools guys are cooperating on this plan, i have some doubt
> on the wisdom of making it the default).

Eh, what?

Isn't it simply the exact same thing as 3) just with a builtin default
list of tools to attempt?

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

This smells like a (possibly big) topic in itself. I'll comment on this

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

I actually think you are wrong here: A bad design is bad even if noone
shouted about it at the "right" (defined by you) time.

Giving only a limited timeframe to raise concerns is not the Debian
way. But perhaps the Kernel maintainers has adopted a different group
dynamic internally?

(I sure don't like how Maximilian and Jeff handled this either, but
that's another issue!)

 - Jonas

- -- 
* Jonas Smedegaard - idealist og Internet-arkitekt
* Tlf.: +45 40843136  Website: http://dr.jones.dk/

 - Enden er nær: http://www.shibumi.org/eoti.htm
Version: GnuPG v1.4.2 (GNU/Linux)


Reply to: