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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
