On Thu, 2015-05-07 at 19:50 -0400, Jate Sujjavanich wrote: > 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.
I'm afraid this assumption is not correct. There are two distinct namespaces we have, the "buildtime" recipe names (PN) and the runtime package names. PREFERRED_PROVIDER takes recipe names (PN), not runtime ones. Mixing the two up is going to cause confusion and problems so the patch as it stands cannot be merged for this reason. > 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. > We have several issues with the way PREFERRED_PROVIDER works today and the translations between build time and runtime. I suspect that code needs rethinking to some extent. I know 5044 is assined to me, as yet I've not been able to find the time it needs to properly think through the different issues and fix it :( Cheers, Richard -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
