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

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

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.

Regards,
Erik




Reply to: