Why not 'uname -r' in externl modules PKGBUILD?

Question

I am in doubt about the correct AUR policy for PKGBUILD of external kernel modules: in the PKGBUILD and in the install file, one has often to refer to the kernel against which the module should be compiled. The best way to do this seems to me to use a 'uname -r', so that the actually running kernel is matched. This is what I have done in a couple of PKGBUILD I contributed.
However I see in the ABS tree and in other PKGBUILDs in the AUR that they often hardcode the reference to the default arch kernel. Is there a reason for this choice? A disadvantage seems clear: the user willing to compile that module on a non-default kernel is called to modify the PKGBUILD. Is there also an advantage? Should I revise my PKGBUILDs according to this prevailing stance?

Answer 1

Common practice, as you have seen, is to create a variable called _kernver, and use that in the build. The principal reason for this is to allow modules to be built for any installed kernel, whether it is running or not. Using `uname -r` only builds the module for the running kernel. The default value for _kernver is the current stock kernel, as the majority of users will be using it.
A practical example - I have kernel26, kernel26ck, and a customised beyond kernel on this machine. If I decide to install a new external module, I can do three builds, one for each kernel, without rebooting, and regardless of which kernel I'm actually using. If I was using `uname -r`, I would have to reboot into each kernel to complete the builds.