Bug 143160

One of the pains for 3rd party kernel module packagers is that that the kernel
package does not contain anything arch-qualified that could be used as a
dependency in order to be able to produce sanely arch-targetted module packages.

The /lib/modules/$uname/build arrangement is ok, but if it contained let's say
/lib/modules/$uname/build.$arch, things would be even better.

Suggested patch attached; it implements the above by placing a build.$arch ->
build symlink, kernel module packages could then have a "BuildRequires:
/lib/modules/$uname/build.%{_target_cpu}" build dependency.

This is untested, because current CVS in devel fails due to diskdump issues,
"kernel/dump.c:32:28: linux/diskdump.h: No such file or directory".

I fail to see the need for this. Can you explain further what you're trying to
do, and how this solves your goal ?

Kernel module packagers need an official, defined "interface" for specifying a
dependency on kernel includes for version $version, arch $arch, in a way that
does not require extra hacks to the build system and that can be expressed in
terms of normal rpm build dependencies.

With the current kernel packaging, there's no way of specifying the architecture
part.

Let's say I want to build a kernel module package for the i686 kernel, so I
rpmbuild it with "--target i686".  I cannot specify that I need the includes
tree configured for i686 in terms of rpm dependencies.  I can only point at
/lib/modules/$uname/build, dig from the config files therein if the
configuration matches what I specified with --target, and fail if not, or to let
the build continue resulting in --target mismatch with the actual configuration
I'm building against.

Now, if I had something in the kernel package arch-qualified so that I could
place a real rpm dependency on it, things would be better; I could let a package
depsolver pull in whatever is the package that provides that arch-qualified.

If the sample patch from comment 1 would be applied to the kernel packages, this
arch-qualified dependency could be implemented in module packages like:

   BuildRequires: /lib/modules/%{kernelver}/build.%{_target_cpu}

...where %{kernelver} is the uname of the target kernel, and %{_target_cpu} is
the arch (automatically populated by rpmbuild according to --target).

The motivation behind this is to get rid of the kernel-module-devel package that
Extras is currently forced to ship in order to have a reliable, relatively
hack-free environment for building kernel module packages.

The scope of my suggestion in this bug is to define the "interface" how module
packages could build-depend on something that provides the kernel includes for
version X, arch Y, and how to locate that directory..  Once this interface is in
place, things could be further optimized while keeping that interface stable
(eg. by moving the headers to another subpackage(s), allowing installation of
include dirs for multiple archs of the same uname in parallel etc).

Adding the symlink as suggested in comment 1 surely wouldn't allow you to have
multiple packages installed simultaneously, and wouldn't help a 'production' run
building modules for a whole bunch of different kernels.

On the other hand, the current kernel-devel packages provide
/usr/src/kernels/%{kernelver}-%{arch}, with the 'arch' component included
specifically to solve this particular problem. What's missing?

Hm. I speak of RHEL4 kernels, and that change hasn't (yet) been made to Fedora
kernels. I wonder why not.... davej?

Past experience regarding kernel-*(devel|source(code)) packaging discussions on
eg. fedora-devel lead me to suggest something I considered as the first step,
and as non-intrusive as possible; ie. asking to define the "interface" only as
the first step, see comment 4.

Without knowing anything about RHEL4 kernels, I can only guess, but the
arrangement you outline in comment 5 sounds very good; it's much more than I
dared to ask right now but it matches the ultimate goal I had in mind :)

In comment 5, does %{kernelver} equal $(uname -r) of that kernel?  How granular
is the packaging in shipping kernel-devel packages, ie. does one package contain
sources only for one %{kernelver} or for all arch variants of it or [...]?  How
are the packages named?

I would be very interested in taking a look at this RHEL4 stuff, and I'm looking
forward to seeing this implemented in FC kernels as well.

This issue ("something arch-qualified") has been covered in devel, so I'll close
the bug.  However, there's still one more pretty critical bit in the current
kernel-devel packages that would be *very* nice to have fixed.  That's bug 145914.