On Tue, 2011-08-02 at 12:26 +0100, Paul Eggleton wrote: > Hi all, > > Andrea pointed out a situation where he has seen the layer priority > overriding > version selection, and I've been able to confirm it. > > Basically, if you have a recipe with a lower version in a layer with a higher > priority it selects the lower version. What's more after digging further I > found there were some rather anomalous interactions with the version logic > and > BBCLASSEXTEND. Here's an example using Poky: > > 1. Firstly, copy meta/recipes-support/curl to meta-yocto/recipes-support, > then > rename the version in meta-yocto so that its version is 7.20.0. At this point > both meta/ and meta-yocto/ have the same layer priority of 5. > > 2. "bitbake -s | grep ^curl" reports: > curl :7.21.7-r0 > > curl-native :7.21.7-r0 > > curl-nativesdk :7.21.7-r0 > > > 3. Now increase the layer priority in meta-yocto/conf/layer.conf to 6, and > run > "bitbake -s | grep ^curl" again: > curl :7.20.0-r0 > > curl-native :7.21.7-r0 > > curl-nativesdk :7.21.7-r0 >
This is clearly broken and needs to be consistent at the very least. > So the latest version here is a lie, this is not the latest version > available. > Furthermore it seems not to have affected the BBCLASSEXTENDs. > > 4. Now add PREFERRED_VERSION_curl = "7.21.7" to conf/layer.conf and run > "bitbake -s | grep ^curl" again: > curl :7.20.0-r0 :7.21.7-r0 > curl-native :7.21.7-r0 > curl-nativesdk :7.21.7-r0 > > So it can clearly see the other recipe, it just doesn't acknowledge it until > you force the matter. > > This is all rather undesirable behaviour IMHO - even if the BBCLASSEXTEND and > reported "latest version available" issues were corrected, I think the policy > of "latest version wins unless DEFAULT_PREFERENCE or PREFERRED_VERSION says > otherwise" should not be affected by layer priority. > > Thoughts? We could do with clearly documenting this in the bitbake manual. I suspect users would expect the highest version to win and we probably should change the behaviour but I'm open to other opinions. Cheers, Richard _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core