-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 22 Oct 2005 08:36:50 +0200 Sven Luther <[EMAIL PROTECTED]> 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-----