Kernel-package, fix version 2 ...

[Sven Luther <sven.luther@wanadoo.fr>]

Hello, 

Apparently the initramfs-tools guys are refusing to implement the
--supported-* policy, and as such, the current packages will not allow to use
initramfs-tools, even though i designed it so that there should be no problem.

Well, after it almost came to blow and bad blood with maks about this
yesterday evening, Jonas made a proposal to change the way it works in an even
nicer way, which would allow the intiramfs-tools guys to stay in their stuborn
isolated ways, and still allow the users to use it. Thanks Jonas, you are a
great guys, and your idea is a good one, i believe.

Anyway, it goes like this :

  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.

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.

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

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.

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

Friendly,

Sven Luther