RFC: When PREFERRED_PROVIDER does not build, don't try other alternatives by default

[Rod Whitby <rod@whitby.id.au>]

Whenever I build virtual/kernel, and for some reason (perhaps a git
fetcher problem, or a patch doesn't apply cleanly) it doesn't build,
bitbake decides to then go and build every other kernel under the sun
trying to complete virtual/kernel.

This is undesirable to the extreme, but I realise that there might have
in the history of OE been a good reason for that behaviour.

My proposal is that bitbake is changed so that if PREFERRED_PROVIDER is
defined, then bitbake does *not* try other providers.  Only if
PREFERRED_PROVIDER is *not* defined should bitbake ever try more than
one package.

Objections?

Here is the IRC log of the discussion with RP about this issue:

<rwhitby> RP: a question for you
<rwhitby> when using virtual/kernel, and your PREFERRED kernel fails to
build, why does bitbake then go and build every other kernel under the sun?
<rwhitby> (and is there a way to stop that happening)
<RP> rwhitby: That is the traditional bitbake behaviour
<RP> rwhitby: I don't actually agree with it but changing it would
breakbacwards compatibilty
<RP> I guess it was once a feature but its turned out no to be so useful
<RP> We should make that behaviour configurable. It only happens with
the -k option anyway
<rwhitby> RP: what was the use case in which it was useful, when
PREFERRED_PROVIDER was defined?
<RP> rwhitby: The idea was it would allow builds to complete rather than
fail
<rwhitby> I can understand it if PREFERRED_PROVIDER is not defined, but
cannot think of a good reason why bitbake should go against explicit
directions for a PREFERRED_PROVIDER
<RP> rwhitby: It comes does to the variable name - "PREFERRED"
<RP> Would it be useful to change the design, I say yes
<RP> but there is history there and as the maintainer I need to be
careful with this
<rwhitby> understood
<rwhitby> can we make it configurable and configure to not do it by
default ?
<RP> We can make it configurable
<RP> I would want to see a discussion about defaults
<RP> Feel free to start that on the bitbake+OE list
<RP> I'm actually in favour of changing it
<RP> but it must be discussed
<rwhitby> nod

-- Rod