The current kernel-devel packages seem to be mostly fine for building external module packages. However, there's one flaw: the directories below /usr/src/kernels do not contain the exact uname of the target kernel, for example /usr/src/kernels/2.6.10-1.1107_FC4-smp-i586 The problem is the extra hyphen between the "base uname" and the variant, "smp" in this case. Removing that hyphen and providing an exact uname would ease the task of finding the correct directory for kernel $uname, since that could be used as-is without having to resort to homebrew solutions and special casing non-UP kernels. "Want to build for kernel with uname XYZsmpfoo, arch i686? Point your build process at /usr/src/kernels/XYZsmpfoo-i686." would Just Work(tm). It would also be analoguous and consistent with everything else kernel related stuff, like /boot/vmlinuz-$uname, /boot/config-$uname, /lib/modules/$uname etc. With the finite set of kernel variants provided by Red Hat, the problem isn't disastrous, but it is a bad one when working with custom kernels. Every module package would have to know all possible variants of target kernels; that is not a solvable equation. So, this: /usr/src/kernels/2.6.10-1.1107_FC4-smp-i586 ...should become: /usr/src/kernels/2.6.10-1.1107_FC4smp-i586 ...ie more generally, /usr/src/kernels/$uname-$arch, not /usr/src/kernels/$base_uname-$variant-$arch. Suggested patch attached, *please* consider making this change before any kernel-devel packages are released outside Rawhide. I was not able to test the patch because the kernel is not currently buildable from my CVS checkout, but I expect the patch to work.
Created attachment 110109 [details] Use uname as-is in kernel-devel directories
ping?
But surely uname is only useful for the _current_ kernel, and you can find the build tree for that in /lib/modules/`uname -r`/build as always. For other kernels than the currently running one you need a different solution anyway.
/lib/modules/`uname -r`/build is not sufficient, because it is not arch-qualified, ie. it does not contain "i686" etc. See bug 143160. uname is useful for others than the current kernel. For example, the "standard" way of building for a specific uname kernel and arch for many 3rd party module packagers has been something like: rpmbuild -bb --target i686 --define 'kernel 2.6.10-1.741_FC3smp' ...and in the specfile, one can add: Requires: /path/to/%{kernel}-%{_target_cpu} ...assuming the kernel source tree lives at /path/to/2.6.10-1.741_FC3smp-i686, and point the build process at that. Problem solved: proper rpm build dependency in place, and a directory to point the build at. With the current kernel-devel packages, one would have to place some magic into every kernel module specfile for resolving an arch-qualified directory for uname $uname, which is caused by the extra hyphen between the "base uname" and the variant as outlined in the intial comment. Of course, this is just one way to solve the problem. If you have other suggestions that meet the requirements (must be able to specify something uname and arch qualified in a reliable way), those would be appreciated. I believe what I suggest is the least intrusive one though, when both kernel and the myriad of module packages out there are considered.
Nominating for FC4 as test1 is coming closer. Any news to share here? Getting this fixed would allow us to modify the Extras kernel-module-devel package for compatibility with kernel-devel, as well as start writing basic kernel module packaging docs for Extras. I'd be happy to provide more info, just ask if more is needed. The kernel-devel packages in Rawhide are _so_ close to being _really_ useful and easy to use that it's painful to see this last bug (*knocks wood*) standing as FC4 is closer every day... :/
David (and Dave), I'm also involved packaging kernel modules for extras and another major repo. This additional "-" makes writing spec-files way harder for no good reason I can see. Ville gave very good reasons why this should be changed -- I don't want to repeat them, they are all valid from my point also. So do you refuse to drop it? Did you use this scheme in RHEL4 and now want to stick with it in Fedora?
Certainly it would make more sense to have done it that way, I agree. I need to investigate this 'standard' way of building external modules, and understand why it can't cope. We also need to consider the implications for compatibility with RHEL4, but I don't really see that's too much of an issue. I plan to look at it shortly when certain other things are out of the way. I haven't been looking at the FC4 kernel at all recently. It doesn't even boot on PPC -- what's the point? :)
Thank you. At the risk of being overly verbose again: the basic problem boils to this: Given an arbitrary kernel "uname -r" and arch, it is not possible to derive the arch-qualified source directory from them without additionally making assumptions on what part of the uname is the variant. For current Rawhide kernels, the variant set {smp,xen0,xenU} as the assumption would work, but that is not enough for non-FC, custom kernels. Let's say I build custom kernels based on the FC ones, and implement them as a "variant", just like Red Hat does (smp,xen0,xenU). The packages are named eg. kernel-vs-2.6.10-1.760_FC3, and the "uname -r" will be 2.6.10-1.760_FC3vs. Now, to derive the source dir, module packages would need to know that an extra "-" needs to be added between "FC3" and "vs" to find the arch-qualified source dir. I see no way they can do this reliably without having the "vs" added to their list of known variants. I guess it is possible to reliably derive the corresponding "uname -r" from a given source directory containing the extra "-" without making too many (if any) assumptions, but I'm afraid that does not help. Is kernel-devel already implemented in RHEL4 with the extra "-" in the dir name? If yes, is it already frozen wrt. this?
My concern is that you're _not_ given 'uname -r'. You actually have to piece that together for yourself _anyway, surely? If you want to build a full set of kernel modules for Fedora Extras, for example, surely the best thing you have to go on is the set of kernel-*-2.6.10-* binary RPMS? And that nomenclature is different _again_. We need to consider this from the point of view of a simple script which can build modules for a full set of kernels, and I don't see how the output of 'uname -r' is relevant to that. Am I missing something?
fish /home/dwmw2 $ cat asd kernel-2.6.10-1.760_FC3.ppc.rpm kernel-vs-2.6.10-1.760_FC3.ppc.rpm kernel-smp-2.6.10-1.760_FC3.ppc.rpm kernel-2.6.10-1.760_FC3.ppc64.rpm kernel-vs-2.6.10-1.760_FC3.ppc64.rpm kernel-smp-2.6.10-1.760_FC3.ppc64.rpm fish /home/dwmw2 $ cat asd | sed 's:kernel\(.*\)-\(2.6.*\)\.\([^.]*\)\.rpm:/usr/src/kernels/\2\1-\3:' /usr/src/kernels/2.6.10-1.760_FC3-ppc /usr/src/kernels/2.6.10-1.760_FC3-vs-ppc /usr/src/kernels/2.6.10-1.760_FC3-smp-ppc /usr/src/kernels/2.6.10-1.760_FC3-ppc64 /usr/src/kernels/2.6.10-1.760_FC3-vs-ppc64 /usr/src/kernels/2.6.10-1.760_FC3-smp-ppc64
This is good food for thought, thanks. Will play around with it a bit and follow up later, but it might take until tomorrow.
Ok, it is possible to use the kernel-*-devel packages as they currently are in Rawhide. But my request for changing the source dirs to use "uname -r" still holds. If compatibility is a concern, the hyphenless ones could be included as owned symlinks. See http://koti.welho.com/vskytta/kmods/ kmods.txt contains various requirements and use cases for kernel module and -devel packages, and the two specfiles implement these use cases. kmodtest-with-uname.spec uses the "uname -r" approach and assumes that the "extra hyphen" as outlined earlier here is gone from the source dir's name. kmodtest-with-nvr.spec uses a name-version-release approach and assumes that the kernel-devel source dir names will stay as they are currently in Rawhide. So, both are doable, but I have no doubt which approach would be better in terms of... uh, well, everything :) The only case where the "nvr" approach "wins" is case 4, and even there, very slightly. I am not convinced if that case is actually too real-world-relevant. You should be able to experiment with the specfiles using "rpmbuild -bp --nodeps", and watching the output. See kmods.txt for examples.
Setting DEFERRED after discussing this with David in PM. To summarize: it's not clear that using "uname -r" is The Ultimate Correct Way in the first place, it's just one possible approach. Making changes now would be possibly incompatible with RHEL4 which we surely don't want without a good reason. And adding compatibility symlinks doesn't necessarily make sense either, as there's not really anything "standard" out there to be compatible with (no, I don't consider fedora.us kernel-module-devel really _that_ standard). Additionally, there are things that clearly _are_ bugs that need work out there (eg. bug 147553, and how module packages should be arranged so that they're buildable with the Extras buildsys when it's available), better to spend time on that stuff first, and revisit this issue later if need be. BTW; I have a new version of fedora.us kernel-module-devel available that makes it forwards compatible with kernel-devel in Rawhide. If someone wants to try it out, mail me.
Created attachment 112398 [details] Use uname as-is in kernel-devel directories, rev 2 Here's a new version of the patch, this one would preserve backwards compatibility. Untested, "should work", I've never managed to build the kernel packages from CVS...
I've applied Ville's patch as-is. It should be in the next rawhide kernel.
Works for me, thanks.