[oe] [PATCH] kernel.bbclass: provide virtual/kernel-${PV}

Tom Rini tom_rini at mentor.com
Tue Feb 22 02:00:04 UTC 2011


On 02/21/2011 05:42 PM, Andreas Oberritter wrote:
> Ping. Is there any reason not to apply this patch? Is there a better way
> to solve the problem?
>
> On 02/11/2011 02:25 PM, Andreas Oberritter wrote:
>> On 02/11/2011 02:18 PM, Koen Kooi wrote:
>>> On 11-02-11 14:02, Andreas Oberritter wrote:
>>>> * Allow precompiled modules to depend on a specific kernel version.
>>>
>>>> Signed-off-by: Andreas Oberritter<obi at opendreambox.org>
>>>> ---
>>>>   classes/kernel.bbclass |    2 +-
>>>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>>> diff --git a/classes/kernel.bbclass b/classes/kernel.bbclass
>>>> index 0d1b4ad..55e3ca0 100644
>>>> --- a/classes/kernel.bbclass
>>>> +++ b/classes/kernel.bbclass
>>>> @@ -1,6 +1,6 @@
>>>>   inherit linux-kernel-base module_strip
>>>
>>>> -PROVIDES += "virtual/kernel"
>>>> +PROVIDES += "virtual/kernel virtual/kernel-${PV}"
>>>>   DEPENDS += "virtual/${TARGET_PREFIX}gcc virtual/${TARGET_PREFIX}depmod-${@get_kernelmajorversion('${PV}')} virtual/${TARGET_PREFIX}gcc${KERNEL_CCSUFFIX} update-modules bluez-dtl1-workaround"
>>>
>>>>   # we include gcc above, we dont need virtual/libc
>>>
>>> How is PV know before the kernel is built? The line below has a
>>> workaround for that, so I guess it also needs one in PROVIDES, no?
>>
>> KERNEL_VERSION is what's unknown until after the build. PV is the
>> version set by the recipe. The line below uses PV to derive 2.4 or 2.6
>> from that.

Does this mean we sometimes create package files with unresolvable / 
incorrect deps?  Or just that it's a bit tricky looking at times?

-- 
Tom Rini
Mentor Graphics Corporation




More information about the Openembedded-devel mailing list