[OE-core] Conflicting providers for ssh/sshd (dropbear and openssh)

[Phil Blundell]

On Wed, 2011-06-29 at 10:42 +0100, Richard Purdie wrote:
> Speaking as the person who likely added this code in the first place,
> its not quite this simple. There are two problem cases:
> 
> a) When we have several recipes like external-toolchain, glibc, eglibc
> and uclibc all of which provide virtual/libc. If something else in the
> build wants say eglibc-locale-foo but the preferred provider of
> virtual/libc is uclibc then what bitbake is trying to warn about is that
> it the user isn't going to get what they expect as both uclibc and
> eglibc could end up being built.

In the particular case of uclibc vs eglibc, this isn't going to happen
because the COMPATIBLE_HOST logic will only ever admit one or the other
to the set of allowed recipes.  And, in the general case of arbitrary
packages, the point I was trying to make earlier is that the user might
actually _want_ to build two things which happen to both provide the
same virtual, and shouldn't be prevented (or even necessarily
discouraged) from doing so.

If there are other cases like the eglibc/uclibc thing which aren't
"intrinsically safe" in the same way then I guess the right way to solve
that is via some kind of (R)CONFLICTS declaration and smarter dependency
processing within bitbake.

> b) There is also the case where two recipes might generate the same
> package. There is also some code in bitbake which at least tries to flag
> problems like that from the point of view of multiple runtime providers.

As with the sysroot thing, I think the place to detect and diagnose that
is at the point where the packages are generated.  Or, alternatively
(but slightly less robustly) you could just scan PACKAGES for all the
recipes in the runqueue and look for collisions there, which would allow
you to detect at least some problems sooner.  I don't think the list of
PROVIDES is sufficiently reliable to use for this purpose since you can
easily have both false positives and false negatives.

p.