Re: Kernel-package, fix version 2 ...
On Sat, Oct 22, 2005 at 08:36:50AM +0200, Sven Luther wrote:
> 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
Sounds workable, and it's something you can build in the kernel install script
without need for support from initrd/initramfs builders; I could live with that :-)
Perhaps we can simplify this further:
* have list of alteratives built into the kernel installer,
* allow ramdisk= in an /etc file to override this,
* run them all,
* and the first one that has exit status 0 and a non-empty image as output wins.
The nice bit about this is that it should survive with odd version
requirements like: initrd-tools works for 2.6.12, but not in combination with lvm.
The only requirement is that generators do not lie about success in their exit
status, but no flags are needed.