Re: Conflicting providers for ssh/sshd (dropbear and openssh)

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Wed, 2011-06-29 at 10:51 +0100, Phil Blundell wrote:
> 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

glibc/eglibc?

external-toolchain?

This area used to be a world of pain for users as bitbake would merrily
go and build a ton of conflicting stuff and the user would be left with
no idea what was going on.

Before that code was in bitbake, it was a major frustration of users and
whilst there are issues like the ssh one, in general the current code
has done orders of magnitude more good than harm. I believe there is
also a whitelist variable to say "we really don't mind multiple
providers of X" too so there may actually be an already existing way to
work around this issue.

>  then I guess the right way to solve
> that is via some kind of (R)CONFLICTS declaration and smarter dependency
> processing within bitbake.

Likely yes but the trouble is you then have to explicitly mark two
things as conflicting so as soon as you add something new to the mix,
the mechanism doesn't work.

This also means adding *CONFLICTS support to bitbake which is something
we've wanted to do for a long time but never got around to.

> > 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.

I don't disagree but as things stand PROVIDES has actually been vert
helpful to users in general, certainly its better than doing nothing.

Cheers,

Richard