[OE-core] [bitbake-devel] [0/2] Yocto Bug #6149, #5044
Richard Purdie
richard.purdie at linuxfoundation.org
Sat May 9 08:31:53 UTC 2015
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
More information about the Openembedded-core
mailing list