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

[Esben Haabendal]

On Thu, 2011-03-17 at 21:00 +0000, Phil Blundell wrote:
> On Thu, 2011-03-17 at 20:58 +0100, Esben Haabendal wrote:
> > 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?

Of-course.  All recipes providing something for  a do_stage must be
build up till the do_package stage, so I can unpack the actual target
packages needed.

> In that case it doesn't seem as though
> installing the unnecessary ones in the sysroot is all that big a
> hardship.

It is not to save time, it is about controlling what goes into a build.
As many software packages scans for presence of various components
through the availability of headers and libraries, I believe it is
important to decide not just what goes into the stage directory, but
also what does not.  So in OE-lite, if I say I depend on libfoo, I do
not get foobar, just because it was built by the same recipe.

> > 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.

Example:

I build recipe A.
Recipe A depends on package B-b from recipe B.
Recipe B depends on package C-c from recipe C, and D-d-native from
recipe D.
Recipe A only get's package B-b staged, unless the B-b package has
specified some build-time dependencies.

This is relevant both for target library and native tools dependencies.

> > 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.

Yes, I get your point.  You could of-course still specify build
dependencies using recipe names/provides, and then just unpack all
target packages build by that recipe.

This would give you the major part of the KISS win I see, except for in
the dependency handling code of BitBake (and in the learning curve of OE
developers).  Keep in mind that by using packages for build-time
dependencies, the mechanism is exactly identical for run-time and
build-time dependencies.  Exactly the same code in BitBake handles both,
and the same mechanism needs to be understood.  This is also part of the
KISS win of doing it this way.

> > 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?

What exactly do you mean?  (We are doing several things with library
package naming...)

/Esben