[...] > > > > 3. Use separate build tree approach and ship single kernel sources > that point > > to different kernel build trees that are distributed as separate packages. > > (link established by kheader) That saves us overhead of having sources > > n x times. It almost certainly requires Makefile fiddling but not very > large. > > It may fail for some non-conformant Makefiles (but then anything can fail) > > <disclaimer type="kernel 2.6 newbie"> > Since the binary kernel packages ship with vmlinux and binary modules, > can they not be linked into the kernel-source-$flavour package, so that > you need kernel-source-base and kernel-source-$flavour (which requires > kernel-$flavour), thus avoiding the need to include two copies of many > files? kernel-source would be a virtual provides in kernel-source-$flavour. > > This assumes either modpost can use compressed modules, or we ship > uncompressed modules in kernel binary packages (or some similar solution). > > Of course, if this is what you meant, just ignore me. > </disclaimer> >
no you are right it is exactly what I meant in next paragraph 4. This requires possibly non-trivial changes in makefiles (at least non-trivial with my level of experience with gmake). Besides there is quite nasty issue - how do we know to use kernel binaries and not in-tree modules? it is new can of worms. > > > > > 4. Teach modpost to extract module versions from /boot/vmlinuz and > /lib/modules. > > Any takers? :) > > > > So far two most attractive approaches are > > > > - disable modversions. Frankly speaking, it was meant to allow people > to reuse > > modules across different kernel versions - as it stands now I have > never seen > > that module from one release could be loaded on another. It seems to > be more > > trouble than it is worth. > > You don't maintain binary kernel module packages I think? If it does > work, it would make life easier ... > just that I understand. You think it makes sense to go without modversions or not? I personally do not like removing it (it gives extra safety); but if it the only option so far I would better turn it off and let people test kernel. > > > > - take approach 3. We need to teach users how to use 2.6 kbuild > anyway, there > > is quite a bit of jump, so we may teach them how to use separate build > tree > > at the same time. > > Option 4 looks the best long-term solution (and useful to others too). > if you manage to convince kbuild maintainers to supply makefile part I promise to add compressed modules support to modpost. It is not as hard (on the verge of being trivial :) -andrey
