5044 2013-08-23 14:20:50 +0000 bitbake does not take into consideration some forms of PREFERRED_PROVIDERS 2016-04-15 06:07:11 +0000 1 1 7 Build System, Metadata & Runtime BitBake bitbake unspecified x86 Multiple RESOLVED FIXED Medium enhancement 2.1 1 cristian.iorga richard.purdie daro jatedev poky.bs.watcher poky.watcher --- --- No (bug/feature does not impact docs) oldest_to_newest 35888 0 cristian.iorga 2013-08-23 14:20:50 +0000 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'] Now the right fix at this point would look at least like this (added in meta/conf/distro/include/default-providers.inc): PREFERRED_PROVIDER_libasound-module-bluez ?= "bluez4" Instead, it looks rather puzzling: PREFERRED_PROVIDER_bluez4 ?= "bluez4" Explanation: Bitbake is faced with "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/bluex5 into the virtual/bluez But that does not happen; 50874 1 jatedev 2015-05-07 23:51:16 +0000 I came across these bugs in poky 1.6.3 (daisy) with multiple package providers. I fixed bug 6149 with just bitbake patch. I came across another bug with this when I tried the bitbake fix on master. With the test case IMAGE_INSTALL_append = " sshd" PREFERRED_PROVIDER_sshd="dropbear" meta/lib/oe/package_manager.py reported a package not found in the base feeds. The file image.bbclass starts copies IMAGE_INSTALL to PACKAGE_INSTALL and performs fix ups for multilib, etc. I added another function (rootfs_process_preferred_providers) to replace sshd in PACKAGE_INSTALL with dropbear. This eliminated the error. The mega-manual is vague when it describes what can be specified in PREFERRED_PROVIDER: an item. And the code partially supports run-time packages as a valid item on the left. My implementation assumes a package name on the right. Yocto bug 5044 suggests traversing from the package name to the virtual/* provider, but I have not thought through how this might work. IMAGE_INSTALL_append = " libasound-module-bluez" PREFERRED_PROVIDER_libasound-module-bluez="bluez4" I got this working on poky 1.6.3, but some changes to the bluez recipes on master seemed to mitigate the original problem. See the bitbake/oe-core mailing list for the patches. 60997 2 richard.purdie 2016-04-10 10:25:27 +0000 Note that there is no virtual/bluez in this case to end up looking up, there is simply no way for bitbake to know which one to use and no syntax to tell it. There would appear to be a genuine case here for PREFERRED_RPROVIDER. 61277 3 richard.purdie 2016-04-15 06:07:11 +0000 The checking of provides was already added previously, we've now added PREFRERRED_RPROVIDER support (http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=9f374c4e8523430ef2fc5cb492c3ece9786623d2) and updated the confusing provider (http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=7f9d01eb177021c022230ca15c293948faa1d962) so this is now all resolved.