[OE-core] how does "PREFERRED_PROVIDER" interact with layer priorities?

Robert P. J. Day rpjday at crashcourse.ca
Mon Feb 17 12:01:34 UTC 2020


  (note: when i finally learn python, i'll be able to RTFS and figure
out stuff like this without assistance. until then ...)

  was going to enhance the explanation of PREFERRED_PROVIDER in the
docs, until i realized i don't understand it completely.

  first, if there is a recipe named, say, "foo", then even if there
are other recipes (with different names) that include:

  PROVIDES = "foo"

by default (and ignoring layer priority complications), if there is a
dependency on "foo", it is the "foo" recipe that will be selected as
the provider, correct? that is, if there is a recipe that *exactly*
matches the name requested, that's the selected provider?

  conversely, if one wants to override that default selection, one
would need to:

  PREFERRED_PROVIDER_foo = "foo_experimental"

in short, if the above is true, then there would seem to be no value
in ever stating:

  PREFERRED_PROVIDER_foo = "foo"

but i just noticed that that's done a fair bit in oe-core's
default-providers.inc, as in (just a few examples):

  PREFERRED_PROVIDER_opkg ?= "opkg"
  PREFERRED_PROVIDER_pkgconfig ?= "pkgconfig"
  PREFERRED_PROVIDER_openssl ?= "openssl"

that puzzled me until i saw this snippet from the same file:

  # Alternative is ltp-ddt in meta-oe: meta-oe/recipes-devtools/ltp-ddt/ltp-ddt_0.0.4.bb
  PREFERRED_PROVIDER_ltp ?= "ltp"

which inspired the conclusion that if there is a higher priority layer
that provides that recipe name, *that* recipe would be used instead.
and since prio of oe-core is 5 and prio of meta-oe is 6, if you want
the *regular* oe-core recipe of "ltp", you need to explicitly ask for
it. is that what's going on here? because if it isn't, then i'm
unclear on the purpose of lines like the above.

rday

p.s. ironically, i was just going to see what meta-oe's recipe of
"ltp-ddt" was doing, but that recipe was deleted so, at the very
least, that comment should be removed.


More information about the Openembedded-core mailing list