-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 22 Oct 2005 08:36:50 +0200 Sven Luther <[EMAIL PROTECTED]> wrote:
[regarding kernel-package becoming smarter at picking ramdisk-tool] > 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. I think it is bad to put this intelligence into the package postinst (as is currently the case as I understand it). Instead, have the kernel packages only declare some "capabilities", and let a separate kernel-install-helper deal with the actual install. This ended up being a quite long email - it took me all day to write. If response is positive it would probably make better sense to post it on the wiki, but perhaps I am silly and you've already discussed (and turned down) things like this long ago... Let's for a moment assume we are dealing not only with linux-2.6, but the following source packages: linux-2.4 linux-2.6 hurd kfreebsd-5 Our current ramdisk handling only relates to linux-2.6 (and linux-2.4 if anyone wanted to do maintain that) but other capabilities like netboot support may be relevant across kernel types. My point here is I want a tool that is generic across (Linux and non-Linux) kernels, and usable for ramdisk generators, bootloaders and other tools dealing with kernels. Even if right now we want to solve a linux-specific, ramdisk-tool-specific problem. A concrete example in the not-so-distant future (based on a true story on #debian-kernel yesterday): Sesse wants to upgrade his machine to 2.6.15. He uses EVMS and is currently running 2.6.12. Announcing kernel capabilities - ------------------------------ The package linux-kernel-2.6.15-1-k7 includes the following file: /boot/linux-2.6.15-1/kernel: linux-initramfs linux-sysfs ext2fs linux-devmapper ext3fs Third-party module package (and perhaps later on: module packages generated from linux-2.6 source) can add their own files in same dir. Perhaps later it would make sense to move module capabilities like linux-devmapper and (for x86 but not powerpc) ext3fs out to a separate /boot/linux-2.6.15-1/kernel-modules, so tools like braindead bootloaders can query builtin capabilities instead of only builtin+modular ones. But that's another story... Installing the kernel - --------------------- The package linux-kernel-2.6.15-1-k7 recommends "kernel-install-helper". In postinst the kernel package invokes "kernel-install-helper" to take care of whatever it takes to finalize the kernel installation - selecting a ramdisk, install/update bootloader, wrap kernel itself (needed for some bootloaders and used to be needed for use with etherboot). If kernel-install-helper does not exist the postinst simply falls back to old-style builtin script. Selecting ramdisk tool - ---------------------- The first implementation of kernel-install-helper does exactly the same as proposed for kernel-package v2 (order reversed here compared to earlier discussion): 1) If ramdisk=[colon-seperated list of tools]: try them one by one: a) If tool does not exist, skip to next tool b) If tool does not accept host and target kernels, skip to next tool c) Use tool blindly. If tool fails, fail with error d) if no tools left, fail with error 2) If ramdisk=[a single tool]: use tool. If tool fails, fail with error 3) If ramdisk=[undefined]: use builtin list and do like 1) That's v1 of the implementation. Let's start with that! Second implementation do similar, but instead of the current "run if acceptable with this host and target kernel versions", it first queries all tools for a list of supported/required capabilites of both host and target kernels. Yaird would respond that it requires "linux-initramfs,linux-sysfs" for both host and target kernels (which equals kernels since 2.6.8), and that it supports "ext2fs,ext3fs,xfs" (but not yet linux-evms). initramfs would respond (I guess) that it requires nothing for host kernel but "linux-initramfs,udev" for target kernel (or whatever is the reason behind the current 2.6.12 restriction). So adjust the logic for v1 with following change to case 1b: b) Query tool for --{supported|required}-{host|target}-capabilities I) If query fails: Use tool with --supported-{host|target}-version II) If query returns negative: Skip to next tool III) If query returns positive: Use tool As soon as all (2!) tools that currently support host/target version restrictions have switched to supporting the query mode, we can drop case 1bI. But if Jeff and Maximilian for some reason choose to add version restrictions but refuse to support capability querying then we just leave it support for both. We probably soon want some enhancements - like a "keep-trying" option for case 1c, or interactive choice of ramdisk tool (like dictionaries today) if more than one i valid. But the above should be possible without any changes to the current documented format of /etc/kernel-pkg.conf and - important! - without too much coding, so let's keep it at that first. Oh, and off course the kernel-install-helper package should take over ownership of /etc/kernel-pkg.conf, with debconf support on the TODO list ;-) Using capabilities - ------------------ So, would all these changes lead to succes for Sesse? Well, assuming EVMS requires only the Linux devmapper and initramdisk-tools was either explicitly chosen by Sesse or "elected" by the kernel-helper-tool, then yes. If both yaird and initramfs-tools installed then yaird would be favored due to its kernel-version support, try to run, but fail. The frustrated Sesse would then (as he actually explained on IRC that he tried) uninstall yaird or explicitly choose to use initramfs-tools and it would work as above. A little down the road then... 1) kernel-install-helper would add "required-capabilities" to /etc/kernel-pkg.conf 2) An updated evms package would suggest Sesse through debconf to add "linux-devmapper" to the list of local required capabilities 3) kernel-install-helper would pick initramfs-tools because yaird considered linux-devmapper an unknown (and thus unsupported) target capability Or... 1) A newer yaird would make use of its build-time probing in the wrapper and include "unknown-filesystem" as an (always impossible) requirement when it fails to parse /etc/fstab 2) kernel-install-helper would pick initramfs-tools because yaird includes "unknown-rootfs" as target requirement If EVMS still (as it says in the long description of the package) requires a kernel compiled with kernel-patch-evms applied then Sesse would need to manually add a new file /boot/linux-2.6.15-1/local containing the single word "linux-devmapper". A little down the road then... 1) Kernel patch packages would hint about added capabilities 1) kernel-package would recognize and include kernel patch package capability hints - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDWqoCn7DbMsAkQLgRAmgSAKCI36WyTajWZF301xVI+ofYbMbrKwCeInp4 1FVL+gkdg21CMMP68FFalcw= =pjO4 -----END PGP SIGNATURE-----