As discussed earlier in PM with David: The current kernel and kernel-devel packages in Rawhide break the earlier "contract" of /lib/modules/<uname>/build dir/symlink being the correct one for the corresponding kernel. Specifically, the correctness of the architecture is not taken care of in any way. It is possible to install a kernel-V-R for arch A, and the corresponding kernel-devel-V-R for arch B, which results in /lib/modules/<uname>/build *not* pointing to the devel tree for kernel V-R, arch A. A possible easy fix would be to move the /lib/modules/<uname>/build (and possibly /lib/modules/<uname>/source) symlink(s) from kernel-devel to the kernel package(s). The symlink's target to a /usr/src/kernels/... directory is fine as-is.
He's right. Dave, can we shift the symlinks into the base kernel package instead of the -devel package please?
I'll look into this one, to check if the proposed fix is acceptable.
The symlinks have just been moved into the base package. The next rawhide kernel should no longer have this problem.
Thanks. However, looking at the current Rawhide kernel-2.6.spec, I see the %post scriptlets of xen0-devel and xenU-devel still cd'ing into /lib/modules/.../build for the hardlinking, which will probably be broken now as the build symlink is no longer guaranteed to be there. Shouldn't they be converted to use /usr/src/kernels/... instead? By the way, what's the purpose of the pushd/popd "wrapping" in the %post *-devel scriptlets? The wrapped block already cd's into the same dir as the pushd...
I just committed a fix to change the xen0-devel and xenU-devel %post scripts to hardlink in /usr/src/kernels/... No idea about the pushd/popd wrapping a cd. Absolutely no idea...
OK, the %post scripts have been cleaned up, too.
Everyone satisfied? close?
*** Bug 193477 has been marked as a duplicate of this bug. ***
*** Bug 1352764 has been marked as a duplicate of this bug. ***