BBFILE_PRIORITY confusion

BBFILE_PRIORITY confusion

[Gary Thomas]

I'm building a multi-layered system, something like this:
   meta-manufacturer/...
   meta-platform/...

The idea is that we'll put any packages and support that are
useful for all platforms we make in meta-manufacturer/ and only
target platform specifics in meta-platform/

I had set BBFILE_PRIORITY=6 in meta-manufacturer/ and 7 in meta-platform/

Here's the confusion.  I originally had something like this for our internal
kernel packages:
   meta-manufacturer/packages/linux/linux-manufacturer_2.6.32.bb
   meta-platform/packages/linux/linux-manufacturer_2.6.28.bb
This was due to the fact that some other platform we make is already
using 2.6.32, but we still have some back at 2.6.28

Today, I tried to bring one of those platforms to 2.6.32, so I added
this (exactly as I have done for other platforms already running 2.6.32):
   meta-platform/packages/linux/linux-manufacturer_2.6.32.bbappend
initially leaving the linux-manufacturer_2.6.28.bb in place.

Much to my surprise, bitbake/poky never even reads the linux-manufacturer_2.6.32.bbappend
file!  This seems to be related to BBFILE_PRIORITY - when I swapped the
priorities around, it started to work.  While this gets me moving, I think
it's wrong - I may need at some point for this platform to be able to override
some manufacturer recipe, etc.

It seems to me that BBFILE_PRIORITY is a bit too zealous; barring any other
constraint, I should think that the 2.6.32 recipe should always take precedence.

Am I missing something here, or is it a bug?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: BBFILE_PRIORITY confusion

[Joshua Lock]

On Sun, 2010-11-21 at 04:13 -0700, Gary Thomas wrote:
> I'm building a multi-layered system, something like this:
>    meta-manufacturer/...
>    meta-platform/...
> 
> The idea is that we'll put any packages and support that are
> useful for all platforms we make in meta-manufacturer/ and only
> target platform specifics in meta-platform/
> 
> I had set BBFILE_PRIORITY=6 in meta-manufacturer/ and 7 in meta-platform/
> 
> Here's the confusion.  I originally had something like this for our internal
> kernel packages:
>    meta-manufacturer/packages/linux/linux-manufacturer_2.6.32.bb
>    meta-platform/packages/linux/linux-manufacturer_2.6.28.bb
> This was due to the fact that some other platform we make is already
> using 2.6.32, but we still have some back at 2.6.28
> 
> Today, I tried to bring one of those platforms to 2.6.32, so I added
> this (exactly as I have done for other platforms already running 2.6.32):
>    meta-platform/packages/linux/linux-manufacturer_2.6.32.bbappend
> initially leaving the linux-manufacturer_2.6.28.bb in place.
> 
> Much to my surprise, bitbake/poky never even reads the linux-manufacturer_2.6.32.bbappend
> file!  This seems to be related to BBFILE_PRIORITY - when I swapped the
> priorities around, it started to work.  While this gets me moving, I think
> it's wrong - I may need at some point for this platform to be able to override
> some manufacturer recipe, etc.
> 
> It seems to me that BBFILE_PRIORITY is a bit too zealous; barring any other
> constraint, I should think that the 2.6.32 recipe should always take precedence.
> 
> Am I missing something here, or is it a bug?
> 

This is working exactly as intended, you've told bitbake that the
manufacturer layer has a higher priority so it's using that to satisfy
any recipe it can, regardless of version. If you'd like the platform to
be able to be prioritised over the manufacturer you'd need to adjust the
priority accordingly.

If you want the most highest version recipe to be used, regardless of
layer, you could set the priorities to be the same.

Perhaps you could work around this by having your platforms pin specific
kernel versions when they need an older kernel?

Hope that helps clarify things.

Cheers,
Joshua
-- 
Joshua Lock
        Intel Open Source Technology Centre

Re: BBFILE_PRIORITY confusion

[Richard Purdie]

On Mon, 2010-11-22 at 13:53 +0000, Joshua Lock wrote:
> On Sun, 2010-11-21 at 04:13 -0700, Gary Thomas wrote:
> > 
> > It seems to me that BBFILE_PRIORITY is a bit too zealous; barring any other
> > constraint, I should think that the 2.6.32 recipe should always take precedence.
> > 
> > Am I missing something here, or is it a bug?
> > 
> 
> This is working exactly as intended, you've told bitbake that the
> manufacturer layer has a higher priority so it's using that to satisfy
> any recipe it can, regardless of version. If you'd like the platform to
> be able to be prioritised over the manufacturer you'd need to adjust the
> priority accordingly.
> 
> If you want the most highest version recipe to be used, regardless of
> layer, you could set the priorities to be the same.
> 
> Perhaps you could work around this by having your platforms pin specific
> kernel versions when they need an older kernel?

Or you give the layers the same priority, then the usual mechanisms take
effect. As Joshua says, its doing exactly what its intended to do
though.

Cheers,

Richard

Re: BBFILE_PRIORITY confusion

[Gary Thomas]

On 11/22/2010 08:33 AM, Richard Purdie wrote:
> On Mon, 2010-11-22 at 13:53 +0000, Joshua Lock wrote:
>> On Sun, 2010-11-21 at 04:13 -0700, Gary Thomas wrote:
>>>
>>> It seems to me that BBFILE_PRIORITY is a bit too zealous; barring any other
>>> constraint, I should think that the 2.6.32 recipe should always take precedence.
>>>
>>> Am I missing something here, or is it a bug?
>>>
>>
>> This is working exactly as intended, you've told bitbake that the
>> manufacturer layer has a higher priority so it's using that to satisfy
>> any recipe it can, regardless of version. If you'd like the platform to
>> be able to be prioritised over the manufacturer you'd need to adjust the
>> priority accordingly.
>>
>> If you want the most highest version recipe to be used, regardless of
>> layer, you could set the priorities to be the same.
>>
>> Perhaps you could work around this by having your platforms pin specific
>> kernel versions when they need an older kernel?
>
> Or you give the layers the same priority, then the usual mechanisms take
> effect. As Joshua says, its doing exactly what its intended to do
> though.

Fair enough, but I have to admit that it's certainly not clear in the
documentation that priority overrides version numbers no matter what.

I've changed my setup to use equal priorities as that does what I want.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------