Re: Kernel-package, fix version 2 ...
On Sat, Oct 22, 2005 at 04:40:37PM +0200, Jonas Smedegaard wrote:
> -----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?
Well, actually, it was just factual, so nobody is surprised as Sesse was that
initramfs-tools was not working right now.
Also, it it simportant to note that most tools should (and hopefully do),
return 1 in case of error or strange arguments being passed.
> > 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.
Well, not really, imagine the current case where he has
ramdisk=/usr/sbin/mkinitrd, for some strange reason, or more realistic,
/usr/sbin/mkinitrd.localcopy. I guess this guy don't expect things to break
when installing 2.6.14, right ?
> 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.
So, you did not reply to me on how to handle the guys who didn't really want
to break their system. I think it is fair to stop and ask for confirmation, in
order to avoid them just seeing soem stuff scroll past the screen, maybe among
a huge install run or dist-upgrade from sarge to etch, and then make their
system unbootable.
This is like the "would you really like to format the disk" question, which
default to no in the installer, safety measures, you know.
The alternative is to provide a force_ramdisk field in kernel-img.conf, which
would be unconditionally followed, or maybe preceed the single ramdisk option
by the force keyword or follow it or something.
> > 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?
Well, right now, in case 1), we provide only 1 tool, either initrd-tools for
pre-2.6.13, and yaird (or initramfs-tools) later on, something more advanced
is possible though.
> > 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!
Not really, right now there are some value which are defaulting to stuff like
=K, which is sed'ed to the right values during make-kpkg's rules invocation,
the idea is to have the default set during the rules invocation, and offer a
make-kpkg option or env variable to override it, so it can be set by the user,
or the official kernel packaging.
> > 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.
Well, not when i personally mentioned it to them and made everyone i could see
aware of it, and asking for comments and advice, and the only reply was that i
was crazy to support yaird. And even then i am happy to hear real arguments,
like you did, which made me change my design.
> 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?
Well, debian's way of doing it also upto a point allow for a single maintainer
to singlehandedly hold up the work of the rest of the maintainers working on
related issues, and this is something i believe is bad for debian.
And again, saying go away you are crazy when asked for comment definitively
forfeits any rigth to critic the plan afterward without any kind of
argumentation i could recognize.
Friendly,
Sven Luther
Reply to: