[OE-core] bug in recipe version priorities across layers?

[Martin Jansa]

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,

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20120223/213c57a6/attachment-0002.sig>