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

[K. Richard Pixley]

I have a similar issue to address.  I haven't gone looking, but what I'm 
hoping for is a hard fail exit from bitbake if the PROVIDER isn't 
available.  I'm hoping for either a global switch that turns 
PREFERRED_PROVIDER from advisory to mandatory.  Or, even better, a 
MANDATORY_PROVIDER which is hard fail while other PREFERRED_PROVIDERs 
remain optional.

It's on my of features to add, but our OE tree is over a year and a half 
old now, and an OE merge doesn't seem to be much of a priority here, so 
it could be some time before I get to it.

The rationale here is the same difference I had with Cygnus configure vs 
Autoconf.  Autoconf's job is to infer itself into new environments as 
best it can.  This is great for systems that are compiled once each on 
millions of personal and academic systems of which no two are exactly alike.

However, for commercial grade software, we really do know exactly what 
our environment is and any time the compiling environment doesn't fit 
our expectations, we really would prefer a hard fail immediately so that 
we can track down that difference.

In our case, we want to use virtual packages as a way of selecting 
one-of-N options for our different products.  But there's absolutely no 
reason to even consider using an option that hasn't been specifically 
selected for a particular product.

--rich

Rod Whitby wrote:
> 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
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>