Re: [dylan, master][PATCH] autotools.bbclass: Fix race with sed-native

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

On Mon, 2013-10-07 at 21:44 -0500, Richard Tollerton wrote:
> richard.purdie@linuxfoundation.org writes:
> 
> > On Fri, 2013-10-04 at 20:22 -0700, Saul Wold wrote:
> >> On 10/04/2013 04:35 PM, Richard Tollerton wrote:
> >> This also starts to create more front end bottle next on autotools 
> >> related items before we can really start to parallelize the build.
> >> 
> >> More thought is required on this.
> >
> > Please have a look at the sed-native changes that went into master
> > recently as I think this issue has been fixed differently...
> 
> Indeed, I agree that commit db2eb325 would fix the race... aaaand this
> also makes me 2-for-2 this month on reinventing the wheel. :'(
> 
> But this brings up a question I've been meaning to ask.
> 
> Build reproducibility is reduced (all other things being equal) as more
> external dependencies are introduced. So I would have expected that The
> Right Thing here would have been to specify -native packages as explicit
> dependencies (just like it's always important to comprehensively
> enumerate dependencies). Not to add specific short-circuits to use the
> system package. sed's probably a bad example here since it is rather
> well-behaved -- surely this sort of issue comes up for many other
> packages, though...
> 
> I know that the OE build is horribly slow, but is it really so slow as
> to require short-circuiting native package dependencies such as this?
> Has there been a general architectural decision made over this sort of
> thing? (I'm sorry, I tried to search for one on the mailing list and
> wiki, but couldn't find any.)

Some native utilities cause big problems in the dependency chain. Things
like tar and gzip have caused us big problems in the past. We've made a
conscious decision to require specific versions of tar, gzip and git for
example to ensure builds work as expected.

The list of things we assume are ok is relatively small and we look at
new issues on a case by case basis. I think sed is well enough
established and well enough behaved to be something we can rely on. In
general we don't rely on much. Do you have any other specific things you
worry about? When you start to look at it, the list is rather small...

Cheers,

Richard