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

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

On Wed, 2011-06-29 at 10:08 +0100, Phil Blundell wrote:
> On Wed, 2011-06-29 at 10:56 +0200, Koen Kooi wrote:
> > That's already the case now. The problem is the PROVIDES overlap since
> > the Poky people decided a distro could only have one true ssh
> > implementation instead of choosing it per image. So if your distro
> > doesn't set the PREFERRED_PROVIDER_sshd you get those nagging messages
> > during parsing that scare users and make consultants rich.
> > 
> > OE .dev isn't a lot better with the misguided DISTRO_SSH_DAEMON, but
> > at least it doesn't show those nag messages.
> 
> Fundamentally I think it is just a bug in bitbake that it makes such a
> fuss about overlapping PROVIDES.  It's not unreasonable for both openssh
> and dropbear to be PROVIDEing something like virtual/ssh-daemon (and
> indeed RPROVIDEing an equivalent) but, as you say, any given distro is
> perfectly entitled to want to build both of them and ship them in
> different images and/or feeds.
> 
> I guess what bitbake is really trying to warn about is recipes which
> will install conflicting files into the sysroot.  Obviously in a future
> utopia of per-recipe sysroot construction this would be a non-issue, but
> even with today's level of technology I think it would be fairly easy
> for us to detect when a collision actually happens and issue a sensible
> diagnostic at that point.  That would allow the offending ERROR to be
> removed without causing any real regression.

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.

We used to end up in a mess where bitbake could build the
external-toolchain recipe and some other libcs in parallel resulting an
a what could only be described as a mess. These days this doesn't happen
so much due to bitbake spitting out its dummy earlier on. It is actually
quite hard to detect this problem generically.

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.


So the code does actually stop some pretty nasty breakage from happening
but it isn't perfect and if we can find better ways, by all means...

Cheers,

Richard