default-providers: Set the preferred provider for bluez

There is a need for a default provider for bluez
now that bluez5 recipe is also present.

After the introduction of bluez5 recipe,
the following warnings are displayed:

"NOTE: multiple providers are available for runtime libasound-module-bluez (bluez4, bluez5)
 NOTE: consider defining a PREFERRED_PROVIDER entry to match libasound-module-bluez"

Upon debug, bitbake shows:
DEBUG: checking PREFERRED_PROVIDER_bluez4 (value None) against ['bluez4', 'bluez5']
DEBUG: checking PREFERRED_PROVIDER_bluez4-4.101 (value None) against ['bluez4', 'bluez5']
DEBUG: checking PREFERRED_PROVIDER_bluez4-4.101-r5 (value None) against ['bluez4', 'bluez5']
DEBUG: checking PREFERRED_PROVIDER_bluez5 (value None) against ['bluez4', 'bluez5']
DEBUG: checking PREFERRED_PROVIDER_bluez5-5.7 (value None) against ['bluez4', 'bluez5']
DEBUG: checking PREFERRED_PROVIDER_bluez5-5.7-r0 (value None) against ['bluez4', 'bluez5']

Bitbake is faced with the question "what should provide libasound-module-bluez?"
which is a runtime name. It needs to try and find a PREFERRED_PROVIDER entry
which matches this but those use *build time* naming. So it converts "libasound-module-bluez"
into the canonical ${PN} of bluez4 and bluez5 and then tries to look those up.
What it actually should do is go one step further of mapping bluez4/bluez5
into the virtual/bluez but that does not happen.

Bug opened on this issue: YB5044
https://bugzilla.yoctoproject.org/show_bug.cgi?id=5044

[YOCTO #5030]

(From OE-Core rev: 6f07d066074b1e01ff3c16408812e6b6d5e531ac)

Signed-off-by: Cristian Iorga <cristian.iorga@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

0 files changed, 0 insertions, 0 deletions