Final resolution for the kernel-package ramdisk handling project ...
Hello,
First sorry for the cross post, but as it seems some didn't get my earlier
emails and don't read d-k or their bug reports, i think it is safer :).
After a week long discussion we all reached the following conclusion :
1) The three initrd tools will now support a --supported-(host|target)-version
option, which will allow the kernel-package provided postinst to query
the tool to check if it is supporting the user configuration. host is the
kernel running at install time, while target is the kernel to be
installed. Additionally they all support a virtual package called
linux-ramdisk-tool.
2) /etc/kernel-img.conf ramdisk= field, which previously accepted only a
single entry, now supports a space separated list of entries.
3) the default, previously being just /usr/sbin/mkinitrd, is now a space
separated list, as in the ramdisk= field, this is currently mkinitrd,
mkinitrd.yaird and then mkinitramfs. This is by no way a definite choice,
since i believe that the choice between initramfs-tools and yaird needs
to be taken together, separatedly, and with a bit more experience to
judge on, more on this below.
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.
5) We threat differently the case where the user has specified only one
entry in the ramdisk= field. In this case we first check if it exists (if
not we fail, obviously), and then we have two cases. Either the tool
supports the --supported-* options, in which case we obey them [1], or
they don't (legacy tool package from stable or whatever), in which case
we check for builtin-defaults for each of the three tools, and fail if we
know they are not supported [2]. If none of these failure cases happen,
we use the ramdisk tool.
6) All of this will is in kernel-package 9.008.2, which i will upload today,
and naturally subject to Manoj's approval once he is back, but i believe
that it is done in the spirit of what he would have accepted.
7) kernel packages will need to depend on yaird | initramfs-tools |
linux-ramdisk-tool, and build-depend on k-p (>>9.008.2), but apart from
that, this should be transparent to them.
Well that is it, a long and heated discussion for this i believe good
solution, let's hope we can all be more reasonable next time and actually
listen to the other side :). Special thanks go to Mattia Dongili, Jonas
Smedegaar, Steve Langasek, Maximilian Attems and Batian Blank for having made
this happen, and all the others who either participated in the discussion or
just suffered us arguing.
Ok, so let's not stop in so good way, and handle the two following items next :
1) Let's follow in this suite and make kernel-package follow policy and
debconfify it. It doesn't sound as difficult as i thought it would, and
would allow nicer interaction with d-i, translations and other such.
2) Then we get to make the difficult choice of initramfs-tools vs yaird for
standard, which i predict will end in another round of flamewars, since
both sides have their staunch supporters, and so on. In the end the user
will always have the choice but we should chose a default. I believe that
this should happen (for a first try) when 2.6.14 enters unstable, but can
be revisited afterward, and may depend on arches, and also on feature
set. Two nice links to help in this decision :
(Our wiki page comparing the two solutions)
http://wiki.debian.org/InitrdReplacementOptions
(Jonas's more advanced proposal for a decision depending on supported
feature set of both tools)
http://lists.debian.org/debian-kernel/2005/10/msg00798.html
And remember, we are still on track to release 2.6.14 the same day it will be
released upstream, with almost all arches being supported immediately.
[1] - problem, right now we cannot distinguish a negative reply to the
--supported-* options from them not being supported. A solution involving
returning 1 for normal failure and 2 for --supported-* negative is
investigated.
[2] - currently we fail, but in the future, once kernel-package's
debconfification is done we may have more subtle options, like querying the
user at medium priority or such.
Friendly,
Sven Luther
Reply to: