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

[Esben Haabendal <eha@doredevelopment.dk>]

On Thu, 2011-03-17 at 15:07 +0000, Phil Blundell wrote:
> On Thu, 2011-03-17 at 15:43 +0100, Esben Haabendal wrote:
> > Is OE really in a position to permantly settle for something suboptimal
> > in such a central area?
> 
> No, but rejecting the big bang doesn't mean that we can't make the
> change; it just means that we need to find a way to make the old and new
> arrangements coexist for a transition period.  This is the way every
> other architectural change in OE has been done and I don't see any
> reason that this one needs to be different.

Exactly

> 
> If we really did want to go ahead and have a metadata flag day then no
> doubt there are plenty of other things we would like to change at the
> same time.  But, thus far, this has never seemed to justify the
> disruption of breaking every recipe in both the main OE repo and third
> party overlays.

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.

I think it would be much more worthwhile to put effort into this than to
push for per-recipe sysroot with the current sstate solution.

Having package-based build-time dependencies, using the same packages as
when building run-time images, is much simpler than what is currently
done in OE, while at the same time giving increased flexibility in
specifying the build-time dependencies needed for a recipe and it's
packages.

But you might have to try it out before really understanding why you
cannot live without it ;-)

> I must admit that I'm also slightly unclear about why the change in
> build dependency specifications is a prerequisite for doing per-recipe
> sysroots.

It might not be, but the result will of-course not be the same.

>Is that just an artifact of the way you implemented it in
> OE-lite or is there some fundamental constraint that means it needs to
> be this way?

I don't think there are any fundamental constraint.  Sometimes doing
things right are simply so much easier.  As a result, I already do have
a solution with both per-recipe staging/sysroot and buld-time
dependencies using target packages.  I feel pretty confident that this
was the fast path, which is sort of backed by the fact that it is done,
whereas the path (detour?) currently being worked on in OE is still just
on it's way.

/Esben