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

Final resolution for the kernel-package ramdisk handling project ...


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

  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)

       (Jonas's more advanced proposal for a decision depending on supported
       feature set of both tools)

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

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


Sven Luther

Reply to: