]> git.ipfire.org Git - thirdparty/openembedded/openembedded-core-contrib.git/commit
providers: Add PREFERRED_RPROVIDER support
authorRichard Purdie <richard.purdie@linuxfoundation.org>
Thu, 14 Apr 2016 13:30:52 +0000 (14:30 +0100)
committerRichard Purdie <richard.purdie@linuxfoundation.org>
Thu, 14 Apr 2016 13:56:07 +0000 (14:56 +0100)
commit62eb39d1474d024b204634689071700605c6095c
tree40dff90a36e204b5785ec6eaab2ab1890403f69d
parentc3fa7e561c22786d3ac57d04c367aa50f1b3b820
providers: Add PREFERRED_RPROVIDER support

Sometimes you can end up in a situation where you need to specify that
a specific runtime entity should be provided by a specific entry.

An example of this is bluez where you could end up in a situation where
for example:

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

The only option here is to set something like PREFERRED_PROVIDER_bluez4 = "bluez4"
which is clearly not very informative.

I've actually held off adding RPROVIDER support for a long while as this
does have sigificant potential for misuse. It doesn't for example allow
multiple runtime providers of the same name to coexist, that simply isn't
supported. It therefore doesn't replace some of the name mappings such
as busybox verses coreutils that OE-Core faces as that is a different
problem with different constraints. This mechanism is simply to provide
bitbake with a hint to decide what the dependency tree should look like.

Also, this allows us to stop printing a confusing message telling the user
to set PREFERRED_PROVIDER when the setting needed would be rather ambiguous.

[YOCTO #5044]

Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
lib/bb/providers.py
lib/bb/ui/knotty.py