bug in recipe version priorities across layers?

On 23.02.2012 15:04, Martin Jansa wrote:
> Afaik latest version from layer with highest priority wins. Which
> doesn't always mean latest version globally.
> 
> DEFAULT_PREFERENCE doesn't help e.g. to demote development version in some
> layer with higher priority.
> 
> But PREFERRED_VERSION does work.

Thanks, Martin! I didn't expect that, but it's an explanation. Is this 
documented somewhere? I think OE-classic behaved differently.

I noticed that "bitbake-layers show-overlayed" nicely prints the 
available versions in order of preference. For some packages, I don't 
understand the ordering though, e.g.:

python-setuptools:
  meta-oe              0.6c11-ml3
  meta                 0.6c11-ml3
python-setuptools-native:
  meta                 0.6c11-ml3
  meta-oe              0.6c11-ml3

(I modified bitbake-layers to include PR in its output)

The diff between both layers looks like this:

---

The only occurence of python-setuptools(-native) is:
meta/classes/setuptools.bbclass:DEPENDS += "python-setuptools-native"

Another strange one, this time with unequal versions:

mpfr:
  meta-oe              3.0.0-r4
  meta                 3.1.0-r0
mpfr-native:
  meta                 3.1.0-r0
  meta-oe              3.0.0-r4

Would lowering the priority of meta-openembedded affect its ability to
bbappend OE-core's recipes? Is it possible to lower its priority, or to
raise the priority of OE core, without modifying conf/layer.conf in
either layer?

Regards,
Andreas

>> - The older wpa-supplicant is provided for a different machine.
>> - Both bitbake and openembedded-core are from today's master branches.
>>
>> The problem: The machine I'm building for also picks up version 0.5.10, 
>> unless I eiher copy 0.7.3 from openembedded-core to my layer or delete 
>> version 0.5.10 from my layer. Deleting wpa-supplicant_0.7.3.bbappend 
>> doesn't change the behaviour.

On Thu, Feb 23, 2012 at 05:54:21PM +0100, Andreas Oberritter wrote:
> On 23.02.2012 15:04, Martin Jansa wrote:
> > Afaik latest version from layer with highest priority wins. Which
> > doesn't always mean latest version globally.
> > 
> > DEFAULT_PREFERENCE doesn't help e.g. to demote development version in some
> > layer with higher priority.
> > 
> > But PREFERRED_VERSION does work.
> 
> Thanks, Martin! I didn't expect that, but it's an explanation. Is this 
> documented somewhere? I think OE-classic behaved differently.

Well I think this is bug or at least very unintuitive behavior.

I have use-case where I've added development version of libsoup-2.4:
meta-openembedded/meta-efl/recipes-support/libsoup/libsoup-2.4_2.37.2.bb

just to meta-efl layer and just because webkit-efl is works more
reliable with this version then current stable.

The problem is that even with D_P -1 it becomes default version for
everybody who includes meta-efl before oe-core, more usefull behavior
would be to force people who use webkit-efl to add P_V if they really
want this development version and keep stable one as default for everyone 
else.

> I noticed that "bitbake-layers show-overlayed" nicely prints the 
> available versions in order of preference. For some packages, I don't 
> understand the ordering though, e.g.:
> 
> python-setuptools:
>   meta-oe              0.6c11-ml3
>   meta                 0.6c11-ml3
> python-setuptools-native:
>   meta                 0.6c11-ml3
>   meta-oe              0.6c11-ml3
> 
> (I modified bitbake-layers to include PR in its output)
> 
> The diff between both layers looks like this:
> 
> --- openembedded-core/meta/recipes-devtools/python/python-setuptools_0.6c11.bb	2012-01-18 15:05:39.876945863 +0100
> +++ meta-openembedded/meta-oe/recipes-devtools/python/python-setuptools_0.6c11.bb	2012-01-18 15:10:23.816943155 +0100
> @@ -29,3 +29,5 @@
>  SRC_URI[sha256sum] = "630fea9b726320b73ee3ca6ff61732cb32675b0389be658080fe46383b87a1d3"
>  
>  BBCLASSEXTEND = "native"
> +
> +NATIVE_INSTALL_WORKS = "1"
> ---
> 
> The only occurence of python-setuptools(-native) is:
> meta/classes/setuptools.bbclass:DEPENDS += "python-setuptools-native"

please just send patch removing python-setuptools from meta-oe,
NATIVE_INSTALL_WORKS isn't needed in oe-core world.. and now with
python-setuptools_0.6c11.bb in oe-core it doesn't make sense to keep
both :).

> Another strange one, this time with unequal versions:
> 
> mpfr:
>   meta-oe              3.0.0-r4
>   meta                 3.1.0-r0
> mpfr-native:
>   meta                 3.1.0-r0
>   meta-oe              3.0.0-r4

This also looks like candidate for removal or at least conversion to
.bbappend if there is significant diff between meta-oe and oe-core.

> Would lowering the priority of meta-openembedded affect its ability to
> bbappend OE-core's recipes? Is it possible to lower its priority, or to
> raise the priority of OE core, without modifying conf/layer.conf in
> either layer?

I don't remember exact rules now, but priority is strange combination of
layer.conf priority and order of bblayers.conf which doesn't even behave
the same for .bbclasses and .bb files IIRC, there was discussion about
improving this situation but I haven't seen any patches doing it since
then. FWIW .bbappend files work as expected in any layer.

Cheers,

On Thu, Feb 23, 2012 at 2:01 PM, Martin Jansa <martin.jansa@gmail.com> wrote:
>> Would lowering the priority of meta-openembedded affect its ability to
>> bbappend OE-core's recipes? Is it possible to lower its priority, or to
>> raise the priority of OE core, without modifying conf/layer.conf in
>> either layer?
>
> I don't remember exact rules now, but priority is strange combination of
> layer.conf priority and order of bblayers.conf which doesn't even behave
> the same for .bbclasses and .bb files IIRC, there was discussion about
> improving this situation but I haven't seen any patches doing it since
> then. FWIW .bbappend files work as expected in any layer.

BBFILE_PRIORITY controls recipe priority. BBLAYERS order controls
BBPATH order which in turn controls bbclass/config priority, as things
stand today.

On Thu, Feb 23, 2012 at 10:01:01PM +0100, Martin Jansa wrote:
> please just send patch removing python-setuptools from meta-oe,
> NATIVE_INSTALL_WORKS isn't needed in oe-core world.. and now with
> python-setuptools_0.6c11.bb in oe-core it doesn't make sense to keep
> both :).
> 
> > Another strange one, this time with unequal versions:
> > 
> > mpfr:
> >   meta-oe              3.0.0-r4
> >   meta                 3.1.0-r0
> > mpfr-native:
> >   meta                 3.1.0-r0
> >   meta-oe              3.0.0-r4
> 
> This also looks like candidate for removal or at least conversion to
> .bbappend if there is significant diff between meta-oe and oe-core.

I've checked the diff and there was just patch for newer patchset P4 and
small patch for thumb (long-long-thumb.patch) which is not yet in
upstream 3.1.0, I'll test 3.1.0 on armv4t and send patch adding
long-long-thumb.patch to oe-core version and drop it from meta-oe.

Cheers,