Re: Kernel-package, fix version 2 ...
-----BEGIN PGP SIGNED MESSAGE-----
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.
Agree.
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,
right?
> 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
separately!
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDWk9ln7DbMsAkQLgRAgxBAJ0dM/akJO+ma5owm/USFIQ6cJLWtgCfRw8j
CNaVNqR+Bc9cFzVTAonH5+E=
=wX32
-----END PGP SIGNATURE-----
Reply to: