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 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? Cheers, Paul (PS: this is not unique to Poky, Andrea and I first reproduced this with Angstrom using bitbake master.) -- Paul Eggleton Intel Open Source Technology Centre _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core