(currently updating my OE/YP courseware, so the first in a number of
admittedly pedantic questions about simple stuff, just to make
absolutely sure i understand things if i'm going to be explaining it
to others. if appropriate, i can submit patches to the official YP
docs if others think it's worth it and has value.)

regarding "PROVIDES =" settings in recipe files, first, each recipe
file implicitly PROVIDES its own recipe name, that much is obvious(?).
so in the simplest possible case, the recipe, say, fubar_1.0.0.bb will
always PROVIDE "fubar" and, if that's the case, there is no value in a
PROVIDES line in that recipe file. that is, it would be silly, but
harmless, for that recipe to include the line:

PROVIDES = "fubar"

next, given that implicit inclusion, the proper way to provide
another name is with "=", not "+=", yes? i ask this as there are a
number of recipe files under openembedded that do just that:

...
meta/recipes-support/libatomic-ops/libatomic-ops_7.6.10.bb:PROVIDES += "libatomics-ops"
meta/recipes-support/libpcre/libpcre2_10.34.bb:PROVIDES += "pcre2"
meta/recipes-support/libpcre/libpcre_8.43.bb:PROVIDES += "pcre"
meta/recipes-graphics/xorg-xserver/xserver-xorg.inc:PROVIDES += "virtual/xserver"
meta/recipes-graphics/xorg-app/mkfontscale_1.2.1.bb:PROVIDES += "mkfontdir"
... etc etc ...

i am *assuming* that, in the absence of a compelling reason, the use
of "+=" instead of "=" in this context is harmless, but unnecessary,
correct?

when would it not be unnecessary? sure, there are cases where a
recipe might require an .inc file which defines a PROVIDES, at which
point the .bb file might append to it. but other than cases like that
(where an earlier PROVIDES actually *needs* to be appended to), is it
safe to say that using "+=" in this context is almost always overkill?

finally, in order to clarify why someone would want to use PROVIDES,
it seems that falls into a few categories. first, to define an
alternative (generally more generic) name for a recipe, such as:

meta/recipes-support/libpcre/libpcre2_10.34.bb:PROVIDES += "pcre2"
meta/recipes-support/libpcre/libpcre_8.43.bb:PROVIDES += "pcre"
meta/recipes-graphics/xorg-app/mkfontscale_1.2.1.bb:PROVIDES += "mkfontdir"

(i guess that would also include when an older package has been
replaced by a newer equivalent alternative.)

second reason is to define virtual providers, such as:

meta/recipes-core/glibc/glibc.inc:PROVIDES += "virtual/libintl virtual/libiconv"
meta/recipes-core/newlib/newlib_3.2.0.bb:PROVIDES += "virtual/libc virtual/libiconv virtual/libintl"
meta/recipes-core/musl/musl_git.bb:PROVIDES += "virtual/libc virtual/libiconv virtual/libintl virtual/crypt"

third reason i can see is in meta-freescale layer, where various
target-dependent u-boot recipes all provide the more generic "u-boot":

recipes-bsp/u-boot/u-boot-imx_2019.04.bb:PROVIDES += "u-boot"
recipes-bsp/u-boot/u-boot-qoriq_2019.04.bb:PROVIDES += "u-boot"
recipes-bsp/u-boot/u-boot-fslc_2019.07.bb:PROVIDES += "u-boot"

the final occasion is when a recipe defines multiple output
packages, so it might contain the line:

PROVIDES = "${PACKAGES}"

at that point, the explanation could finish off discussing
PREFERRED_PROVIDER and DEFAULT_PREFERENCE.

does the above look about right? are there any subtle details of
PROVIDES missing?

rday

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================