]> code.ossystems Code Review - openembedded-core.git/commit
kernel.bbclass: add non-santized kernel provides
authorBruce Ashfield <bruce.ashfield@windriver.com>
Tue, 28 Aug 2012 06:41:47 +0000 (08:41 +0200)
committerScott Garman <scott.a.garman@intel.com>
Mon, 24 Sep 2012 16:51:10 +0000 (09:51 -0700)
commit0af1d1412add1baf3f6c1a5cfb2e4f92fb6a85dc
treef2ed41e6a6c2bb547d572a3e2cb3a09ab4ee1522
parent0e3e88f9f87d1083ddd7dcaa526b3cd7a1cd53ff
kernel.bbclass: add non-santized kernel provides

If the kernel version string uses characters or symbols that
need to be santized for the package name, we can end up with a
mismatch between module requirements and what the kernel
provides.

The kernel version is pulled from utsrelease.h, which contains
the exact string that was passed to the kernel build, not
one that is santized, this can result in:

 echo "CONFIG_LOCALVERSION="\"MYVER+snapshot_standard\" >> ${B}/.config

 <build>

 % rpm -qp kernel-module-uvesafb-3.4-r0.qemux86.rpm --requires
update-modules
kernel-3.4.3-MYVER+snapshot_standard
 % rpm -qp kernel-3.4.3-myver+snapshot-standard-3.4-r0.qemux86.rpm --provides
kernel-3.4.3-myver+snapshot-standard = 3.4-r0

At rootfs assembly time, we'll have a dependency issue with the kernel
providing the santizied string and the modules requiring the utsrelease.h
string.

To not break existing use cases, we can add a second provides to the
kernel packaging with the unsantized version string, and allowing the
kernel module packaging to be unchanged.

   RPROVIDES_kernel-base += "kernel-${KERNEL_VERSION}"

 % rpm -qp kernel-3.4.3-myver+snapshot-standard-3.4-r0.qemux86.rpm --provides
kernel-3.4.3-MYVER+snapshot_standard
kernel-3.4.3-myver+snapshot-standard = 3.4-r0

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
meta/classes/kernel.bbclass