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. ***