[oe] Eliminating dependency race-conditions (was Re: [PATCH] net-snmp: disable libnl use)

[Phil Blundell]

On Thu, 2011-03-17 at 20:58 +0100, Esben Haabendal wrote:
> On Thu, 2011-03-17 at 18:05 +0000, Phil Blundell wrote:
> > On Thu, 2011-03-17 at 18:52 +0100, Esben Haabendal wrote:
> > > Well, it might be possible to minimize the disruption for a transitional
> > > period by carefully specifying some catch-all build-time package
> > > dependencies pulling in all packages for recipes not ported yet.
> > 
> > Yes, that's the sort of thing I was thinking of.  It isn't even totally
> > obvious to me that specifying individual packages is any better than
> > "all packages from recipe X", since with the former you then have a
> > potential maintenance headache if files get moved from one package to
> > another.
> 
> There is a number of ways that I believe package based build
> dependencies are better than recipe based.
> 
> a) It is possible to depend on parts of a recipe, which fx. is useful
> when a recipe provides more than 1 library, where you might not want all
> of them.

You'd still need to have built all of them (at least as far as the end
of do_compile) though, right?  In that case it doesn't seem as though
installing the unnecessary ones in the sysroot is all that big a
hardship.

> b) To build a recipe, you depend on some stuff which you don't need to,
> or perhaps even really don't want to pass on to recipes depending on
> this recipe.

Sorry, I don't understand what you're saying here.

> c) KISS. Using the actual target packages for satisfying build-time
> dependencies are a very simple approach, which I strongly believe will
> make OE a better tool in the long run, by reducing complexity, and thus
> lowering the bar for contributing to OE archictural work.

I agree with this, but it seems unrelated to the question of whether
build dependencies should be specified in terms of recipes or output
packages.

> The maintenance headache you talk about is already there.  In OE-lite
> build-time dependency 95% of the time just follow the run-time
> dependencies, perhaps making it easier to maintain than OE, as we don't
> have to think about another type of "item names" to depend on.

(How) do you deal with library package renaming in OE-lite?

p.