There is use case when newer development version is added to e.g. meta-oe with negative D_P and only users who decide to test/use that version should get it, if they define P_V for this new version. Currently it would became default version for all meta-oe users without P_V specified, which isn't very intuitive. On Fri, Aug 17, 2012 at 01:48:45PM +0100, Paul Eggleton wrote: > This is also undesirable for meta-oe IMHO - as a general principle, meta-oe > shouldn't be trying to both add additional recipes *and* provide newer/older > versions of recipes that are in OE-Core. Please, let's get the new versions > into OE-Core or if they're too risky/broken for some use cases for that, then > they belong in people's distro layers. (Practically I don't think there are > that many instances of new versions of OE-Core recipes that people want to use > that would be actually rejected by OE-Core). What if newer version is needed for recipe which exists only in meta-oe? I had this in meta-efl where webkit-efl was sometimes segfaulting when older stable version of libsoup2.4 was used, upstream solved that by recommending development version of libsoup2.4, but as soon as I've added it to meta-efl everybody (including users which don't use webkit-efl from meta-efl - don't need this libsoup2.4) got it as default. Yes I could have added this libsoup2.4 only to meta-shr (where I had P_V for that) and keep webkit-efl broken for everyone else, or try to add developement version of libsoup2.4 to oe-core..
I've given this some thought and to be honest I think this is working as designed. D_P is the weakest form of preference that can be expressed and its been clearly documented (on the mailing lists at least) that this was always its intent. As such, D_P is of lower priority than layer priority. If layer priority is equal, D_P should then come into play. So given this is behaving as deisgned, I'm going to close this as NOTABUG.
Marked as verified.