[RFC] Stop on multiple providers but none explicitly specified

[RFC] Stop on multiple providers but none explicitly specified

[Leon Woestenberg]

Hello all,

in trying to explain a new user why his build fails, it was the
classic situation of multiple providers available but non specified:

NOTE: multiple providers are available for virtual/libc
(external-toolchain, uclibc);
NOTE: consider defining PREFERRED_PROVIDER_virtual/libc

Now, as far as I know, this makes the build non-deterministic, because
bitbake "just" chooses one.

Why do we want this behaviour? I cannot see any benefit in this situation.

We should at least prefer one over the other, or just bail out in my opinion.

Regards,
-- 
Leon

Re: [RFC] Stop on multiple providers but none explicitly specified

[Richard Purdie]

On Wed, 2008-05-14 at 23:36 +0200, Leon Woestenberg wrote:
> Hello all,
> 
> in trying to explain a new user why his build fails, it was the
> classic situation of multiple providers available but non specified:
> 
> NOTE: multiple providers are available for virtual/libc
> (external-toolchain, uclibc);
> NOTE: consider defining PREFERRED_PROVIDER_virtual/libc
> 
> Now, as far as I know, this makes the build non-deterministic, because
> bitbake "just" chooses one.
> 
> Why do we want this behaviour? I cannot see any benefit in this situation.
> 
> We should at least prefer one over the other, or just bail out in my opinion.

Bitbake will pick one, the options in brackets are in the order bitbake
will choose them. We sort them alphabetically iirc since that is more
deterministic than depending on parsing order which was the previous
approach.

Cheers,

Richard

Re: [RFC] Stop on multiple providers but none explicitly specified

[Tom Rini]

On Thu, May 15, 2008 at 05:42:06PM +0100, Richard Purdie wrote:
> On Wed, 2008-05-14 at 23:36 +0200, Leon Woestenberg wrote:
> > Hello all,
> > 
> > in trying to explain a new user why his build fails, it was the
> > classic situation of multiple providers available but non specified:
> > 
> > NOTE: multiple providers are available for virtual/libc
> > (external-toolchain, uclibc);
> > NOTE: consider defining PREFERRED_PROVIDER_virtual/libc
> > 
> > Now, as far as I know, this makes the build non-deterministic, because
> > bitbake "just" chooses one.
> > 
> > Why do we want this behaviour? I cannot see any benefit in this situation.
> > 
> > We should at least prefer one over the other, or just bail out in my opinion.
> 
> Bitbake will pick one, the options in brackets are in the order bitbake
> will choose them. We sort them alphabetically iirc since that is more
> deterministic than depending on parsing order which was the previous
> approach.

There's still a problem here.  I've sometimes seen external-toolchain
picked for one thing I've forgotten when setting up for uclibc.  Having
the build just fail here would be nice.

-- 
Tom Rini

Re: [RFC] Stop on multiple providers but none explicitly specified

[Leon Woestenberg]

Hello Richard,

thanks for your reply.

On Thu, May 15, 2008 at 6:42 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
> Bitbake will pick one, the options in brackets are in the order bitbake
> will choose them. We sort them alphabetically iirc since that is more
> deterministic than depending on parsing order which was the previous
> approach.
>
I agree it's more deterministic seen from the BitBake point-of-view
and that's an improvement.

However, is it intuitive from the *user's* point-of-view to have
BitBake make this decision?
I think not; at least in the case of OpenEmbedded, there is at least a
50% chance this is not what the user intended.

1) Besides fixing this in BitBake (by bailing out, my first proposal),
2) an alternative solution is to set the preferred provider for the
toolchain/libc elements to a built..
a) ..in each distro file
b) ..globally where we can build the toolchain/libc elements in
OpenEmbedded for the target.

I think 2a)  is not the way OpenEmbedded should work. The distro is
not the authorative component that decides whether we can build a
toolchain/libc for each target (like Angstrom does now).

Shouldn't we do (2b), where the distribution can *optionally* override
the preferred provider if it knows better?

Greetings,
-- 
Leon

Re: [RFC] Stop on multiple providers but none explicitly specified

[Tom Rini]

On Thu, May 15, 2008 at 08:51:29PM +0200, Leon Woestenberg wrote:

> However, is it intuitive from the *user's* point-of-view to have
> BitBake make this decision?
> I think not; at least in the case of OpenEmbedded, there is at least a
> 50% chance this is not what the user intended.
> 
> 1) Besides fixing this in BitBake (by bailing out, my first proposal),
> 2) an alternative solution is to set the preferred provider for the
> toolchain/libc elements to a built..
> a) ..in each distro file
> b) ..globally where we can build the toolchain/libc elements in
> OpenEmbedded for the target.
> 
> I think 2a)  is not the way OpenEmbedded should work. The distro is
> not the authorative component that decides whether we can build a
> toolchain/libc for each target (like Angstrom does now).
> 
> Shouldn't we do (2b), where the distribution can *optionally* override
> the preferred provider if it knows better?

How do we know what's right?  Since in many cases it's glibc OR uclibc
OR external-toolchain, there is no right default there.  If we just bail
out here..
- Distro maintainers know what's right for their distro and lock things
  down (or know the complex table of their correct answers, and lock
  down).
- End users never see this unless the distro isn't up to date, and ping
  the distro maintainer.
- Custom folks get a build that bails out, with a good reason and they
  pick what they know they need here.

-- 
Tom Rini

Re: [RFC] Stop on multiple providers but none explicitly specified

[Leon Woestenberg]

Hello Tom,

On Thu, May 15, 2008 at 10:11 PM, Tom Rini <trini@kernel.crashing.org> wrote:
> On Thu, May 15, 2008 at 08:51:29PM +0200, Leon Woestenberg wrote:
>
>> However, is it intuitive from the *user's* point-of-view to have
>> BitBake make this decision?
>> I think not; at least in the case of OpenEmbedded, there is at least a
>> 50% chance this is not what the user intended.
>>
>> 1) Besides fixing this in BitBake (by bailing out, my first proposal),
>> 2) an alternative solution is to set the preferred provider for the
>> toolchain/libc elements to a built..
>> a) ..in each distro file
>> b) ..globally where we can build the toolchain/libc elements in
>> OpenEmbedded for the target.
>>
>> I think 2a)  is not the way OpenEmbedded should work. The distro is
>> not the authorative component that decides whether we can build a
>> toolchain/libc for each target (like Angstrom does now).
>>
>> Shouldn't we do (2b), where the distribution can *optionally* override
>> the preferred provider if it knows better?
>
> How do we know what's right?  Since in many cases it's glibc OR uclibc
> OR external-toolchain, there is no right default there.  If we just bail
> out here..
>
Yes, bailing out is my first proposal, which modifies bitbake.

"Setting what's right" is a secondary solution, and modifies
OpenEmbedded metadata. I would prefer to default to our self-built
toolchain for targets that have a known "good" cross-toolchain in
OpenEmbedded. We can default to glibc for targets where glibc is the
"best" choice, i.e. bigger targets, and default to uclibc where it
makes sense (your favourite router?).

The distro can override where necessary (this is the exception, and in
most cases it locks down toolchain versions, does not select
providers).

> - Distro maintainers know what's right for their distro and lock things
>  down (or know the complex table of their correct answers, and lock
>  down).
>
Hmm, do I *need* to set a distro?

Does the *distro* limit me to what targets I want to build?

What if I want to build helloworld-image for the microblaze
achitecture? (Just babbling here - but it has MMU now :-).

> - End users never see this unless the distro isn't up to date, and ping
>  the distro maintainer.
>
No. Only very experienced end users ping the distro maintainer. New
end-users complain on #oe, they don't see the NOTE: at the top, and
don't understand why stuff fails.

> - Custom folks get a build that bails out, with a good reason and they
>  pick what they know they need here.
>
Yes, my preference.


But let me put it another way:

The concept of distro's should not restrict me from using OpenEmbedded
as a cross platform build system. Our default configuration should
much mimick buildroot. Select machine, packages, go. We should start
where buildroot ends.

Use cases:

Selecting "MACHINE=microblaze_dev_board, bitbake helloworld-image.bb"
should work out of the box if we add the microblaze toolchain.

Selecting "MACHINE=new_machine_with_new_arch DISTRO=old_distro bitbake
some-image.bb" should as least TRY to build the image for the machine
using the toolchain that is available in OpenEmbedded.

My 2cts,

Regards,
-- 
Leon

Re: [RFC] Stop on multiple providers but none explicitly specified

[Tom Rini]

On Thu, May 15, 2008 at 10:50:58PM +0200, Leon Woestenberg wrote:
> Hello Tom,
> 
> On Thu, May 15, 2008 at 10:11 PM, Tom Rini <trini@kernel.crashing.org> wrote:
> > On Thu, May 15, 2008 at 08:51:29PM +0200, Leon Woestenberg wrote:
> >
> >> However, is it intuitive from the *user's* point-of-view to have
> >> BitBake make this decision?
> >> I think not; at least in the case of OpenEmbedded, there is at least a
> >> 50% chance this is not what the user intended.
> >>
> >> 1) Besides fixing this in BitBake (by bailing out, my first proposal),
> >> 2) an alternative solution is to set the preferred provider for the
> >> toolchain/libc elements to a built..
> >> a) ..in each distro file
> >> b) ..globally where we can build the toolchain/libc elements in
> >> OpenEmbedded for the target.
> >>
> >> I think 2a)  is not the way OpenEmbedded should work. The distro is
> >> not the authorative component that decides whether we can build a
> >> toolchain/libc for each target (like Angstrom does now).
> >>
> >> Shouldn't we do (2b), where the distribution can *optionally* override
> >> the preferred provider if it knows better?
> >
> > How do we know what's right?  Since in many cases it's glibc OR uclibc
> > OR external-toolchain, there is no right default there.  If we just bail
> > out here..
>
> Yes, bailing out is my first proposal, which modifies bitbake.

Perhaps it's time to take this up on the bitbake list? :)

[snip]
> > - Distro maintainers know what's right for their distro and lock things
> >  down (or know the complex table of their correct answers, and lock
> >  down).
> >
> Hmm, do I *need* to set a distro?
> 
> Does the *distro* limit me to what targets I want to build?
> 
> What if I want to build helloworld-image for the microblaze
> achitecture? (Just babbling here - but it has MMU now :-).

I'd think that with a sufficiently filled out local.conf you wouldn't
need a distro conf file, but I could see something being upset that
DISTRO isn't set.

> > - End users never see this unless the distro isn't up to date, and ping
> >  the distro maintainer.
>
> No. Only very experienced end users ping the distro maintainer. New
> end-users complain on #oe, they don't see the NOTE: at the top, and
> don't understand why stuff fails.

Well, for $DISTRO they should poke $DISTRO_RESPONSIBLE_PARTIES, but yes,
I see your point.

> > - Custom folks get a build that bails out, with a good reason and they
> >  pick what they know they need here.
> >
> Yes, my preference.
> 
> 
> But let me put it another way:
> 
> The concept of distro's should not restrict me from using OpenEmbedded
> as a cross platform build system. Our default configuration should
> much mimick buildroot. Select machine, packages, go. We should start
> where buildroot ends.
> 
> Use cases:
> 
> Selecting "MACHINE=microblaze_dev_board, bitbake helloworld-image.bb"
> should work out of the box if we add the microblaze toolchain.
> 
> Selecting "MACHINE=new_machine_with_new_arch DISTRO=old_distro bitbake
> some-image.bb" should as least TRY to build the image for the machine
> using the toolchain that is available in OpenEmbedded.

Personally, I like setting varibles in conf files, but that's just my
workflow, not your workflow :)

-- 
Tom Rini

Re: [RFC] Stop on multiple providers but none explicitly specified

[Koen Kooi]

Leon Woestenberg wrote:

> Use cases:
>
> Selecting "MACHINE=microblaze_dev_board, bitbake helloworld-image.bb"
> should work out of the box if we add the microblaze toolchain.
>
> Selecting "MACHINE=new_machine_with_new_arch DISTRO=old_distro bitbake
> some-image.bb" should as least TRY to build the image for the machine
> using the toolchain that is available in OpenEmbedded.

I've tried to make OE do "the right thing" in the past, but at the time 
the ARM users were strongly divided into seperate camps, with 
conflicting use cases (eg. some people insisted on hard-float, others on 
soft-float).
In the end it was both easier and cleaner (no double _distro_machine 
overrides in gcc_foo.bb) to specify the toolchain in the distro.
Since a few weeks the toolchain portion in angstrom is a log cleaner 
since people can now use subarch overrrides (armv7a, ppc405) to base 
their decision on.

 From a practical POV I'd say "pick a distro that's maintained and 
supports uclibc" for you microblaze board, and you should have very 
little trouble getting it to work.
 From a theoretical POV I'd say "OE should do the right thing", but "the 
right thing" is sadly such a political minefield that makes having a 
distro based with lots of technical merits (subarch overrides, 
modularity, extendability, QA integration, etc) like Angstrom is a blessing.
For years OE claimed "just change the MACHINE and everything just 
works", but it took angstrom nearly two years to make that a reality, so 
don't underestimate the work[1] involved making everything "just work"

regards,

Koen

[1] Just look at the the sheer amount of nasty python code in angstrom 
to select OABI for certain machines in a sane, supportable way....

Re: [RFC] Stop on multiple providers but none explicitly specified

[Richard Purdie]

On Thu, 2008-05-15 at 20:51 +0200, Leon Woestenberg wrote:
> On Thu, May 15, 2008 at 6:42 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
> > Bitbake will pick one, the options in brackets are in the order bitbake
> > will choose them. We sort them alphabetically iirc since that is more
> > deterministic than depending on parsing order which was the previous
> > approach.
>
> I agree it's more deterministic seen from the BitBake point-of-view
> and that's an improvement.
> 
> However, is it intuitive from the *user's* point-of-view to have
> BitBake make this decision?
> I think not; at least in the case of OpenEmbedded, there is at least a
> 50% chance this is not what the user intended.

You're making this sound clear cut and its not quite that easy :).
Firstly, 50% isn't a good figure, there is no limit to the number of
different packages which provide a given target so it could be 33%, 25%
or worse.

Secondly, there often is a good default choice its just bitbake doesn't
have the information to make it. For example, we'd probably all agree
that we'd like bitbake to by default:

Use uclibc for linux-uclibc/linux-uclibcgnueabi builds to satisfy virtual/libc
Use glibc for linux/linux-gnueabi builds to satisfy virtual/libc
Use libx11 to satisfy virtual/libx11

I guess what we could do is give each provider a PROVIDER_PREFERENCE =
"0". glibc then does:

PROVIDER_PREFERENCE_virtual/libc_linux = "1"
PROVIDER_PREFERENCE_virtual/libc_linux-gnueabi = "1"

uclibc does:

PROVIDER_PREFERENCE_virtual/libc_linux-uclibc = "1"
PROVIDER_PREFERENCE_virtual/libc_linux-uclibcgnueabi = "1"

libx11 does:

PROVIDER_PREFERENCE_virtual/libx11 = "1"

etc. and then it becomes a case of having bitbake use this information.
It would then be able to error if more that one entry had the highest
preference for a given provider and yet the sane defaults should work.
This should also mean no specific distro setup is needed yet the distro
can set PREFERRED_PROVIDER statements which override the above
PREFERENCES if wanted.

Does that make sense?

Cheers,

Richard

Re: [RFC] Stop on multiple providers but none explicitly specified

[Leon Woestenberg]

Hello all,

On Thu, May 15, 2008 at 11:45 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
> On Thu, 2008-05-15 at 20:51 +0200, Leon Woestenberg wrote:
>> On Thu, May 15, 2008 at 6:42 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
>>
>> However, is it intuitive from the *user's* point-of-view to have
>> BitBake make this decision?
>> I think not; at least in the case of OpenEmbedded, there is at least a
>> 50% chance this is not what the user intended.
>
> You're making this sound clear cut and its not quite that easy :).
> Firstly, 50% isn't a good figure, there is no limit to the number of
> different packages which provide a given target so it could be 33%, 25%
> or worse.
>
No in fact, the chance of making the wrong decision is 50%, 67%, 75%
(or worse) for n = 2, 3, 4 etc.

(but I think you meant this).

> Secondly, there often is a good default choice its just bitbake doesn't
> have the information to make it.
>
Well this is exactly my point; Let's give bitbake that information for
the remaining cases.

PROVIDER_PREFERENCE seems a bridge too far for me, but hey, any
solution that solves it is better then the current situation.

Regards,
-- 
Leon

Re: [RFC] Stop on multiple providers but none explicitly specified

[Richard Purdie]

On Fri, 2008-05-16 at 23:44 +0200, Leon Woestenberg wrote:
> > You're making this sound clear cut and its not quite that easy :).
> > Firstly, 50% isn't a good figure, there is no limit to the number of
> > different packages which provide a given target so it could be 33%, 25%
> > or worse.
> >
> No in fact, the chance of making the wrong decision is 50%, 67%, 75%
> (or worse) for n = 2, 3, 4 etc.

I was referring of to the chance of making the right decision so yes,
the chance of making the wrong decisions is the opposite and increases
with provider numbers.

> (but I think you meant this).
> 
> > Secondly, there often is a good default choice its just bitbake doesn't
> > have the information to make it.
> >
> Well this is exactly my point; Let's give bitbake that information for
> the remaining cases.
> 
> PROVIDER_PREFERENCE seems a bridge too far for me, but hey, any
> solution that solves it is better then the current situation.

Its the only solution I can see which addresses the problem but it does
further complicate the providers logic in bitbake which is already
painful and in need of rewriting :/. Other solutions welcome... 

Cheers,

Richard

Re: [RFC] Stop on multiple providers but none explicitly specified

[Leon Woestenberg]

Richard,

On Sat, May 17, 2008 at 11:59 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
> On Fri, 2008-05-16 at 23:44 +0200, Leon Woestenberg wrote:
>> PROVIDER_PREFERENCE seems a bridge too far for me, but hey, any
>> solution that solves it is better then the current situation.
>
> Its the only solution I can see which addresses the problem but it does
> further complicate the providers logic in bitbake which is already
> painful and in need of rewriting :/. Other solutions welcome...
>
The idea of bailing out when no preferred provider has been set is
(1) simple
(2) deterministic
(3) simple

Why make it harder then necessary? The stuff is complicated enough as
it is, especially for new ppl.

Regards,
-- 
Leon

Re: [RFC] Stop on multiple providers but none explicitly specified

[Richard Purdie]

On Mon, 2008-05-19 at 00:48 +0200, Leon Woestenberg wrote:
> Richard,
> 
> On Sat, May 17, 2008 at 11:59 PM, Richard Purdie <rpurdie@rpsys.net> wrote:
> > On Fri, 2008-05-16 at 23:44 +0200, Leon Woestenberg wrote:
> >> PROVIDER_PREFERENCE seems a bridge too far for me, but hey, any
> >> solution that solves it is better then the current situation.
> >
> > Its the only solution I can see which addresses the problem but it does
> > further complicate the providers logic in bitbake which is already
> > painful and in need of rewriting :/. Other solutions welcome...
> >
> The idea of bailing out when no preferred provider has been set is
> (1) simple
> (2) deterministic
> (3) simple
> 
> Why make it harder then necessary? The stuff is complicated enough as
> it is, especially for new ppl.

The above is harder than necessary. You run bitbake, find something
isn't set, set it, run bitbake, find something else isn't set, set it,
run bitbake, etc.

"Simple" from the user perspective is that it just works and you don't
have to set anything.

IMO, in 95% of cases a user wants the default virtual provider. The only
problem is that at present bitbake has no way of working out what that
is...

If this worked properly there should be no more nasty issues with
external-toolchain bothering people and angstroms distro.conf should
become a lot simpler...

Cheers,

Richard