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

[Richard Purdie]

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.
> 
> 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.
> 
> 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'd like to step in here and point out that your approach is not as
simple as you claim. It certainly is a really nice solution for one very
specific use case.

There are however many other problems which appear when you step away
from your isolated usecase.

Take the case of different package managers, how is that handled? Can
you only have one enabled at a given time? What happens if you switch
package manager half way through a build. Currently package managers and
package format are abstracted, I suspect we lose that with your
implementation. What if the package managers have slightly different
behaviours?

Secondly, how about task output that isn't packages? The output of
do_deploy for example(kernel/firmware/bootloader)? The pkgdata generated
by do_package? A generic extra task added by the user which outputs some
data?

What you're proposing is to totally actually totally collapse our
current generic task structure into something entirely governed by
target packages and their specific requirements. Of course you could say
the existing mechanisms are still available but then where is the
simplification?

sstate is very simple in concept and very simple in operation compared
to anything we've previously had. It is generic being task based and can
apply to any task as required. It doesn't require radical changes to the
existing model, there is a clear migration path and it also embraces
things like the checksum/signature generation which I believe are going
to play a significant role in the future.

This isn't to say what you're doing is wrong or that we shouldn't be
looking at it for ideas but I believe it needs to be something
incremental on top of what we already have and functionality we have now
cannot simply be lost as people use it.

Cheers,

Richard