Re: Eliminating dependency race-conditions

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

On Fri, 2011-03-18 at 13:14 +0100, Esben Haabendal wrote:
> By doing it this way, I don't think we are getting much closer to the
> second step (package-based build-time dependencies).  The OE-lite
> implementation of per-recipe staging builds on top of package-based
> build-time dependencies, so to do it the other way around, would imply
> taking the sstate concept and extend it to do per-recipe sysroots.
> After that, I believe you have exactly the same amount of development
> left to get where OE-lite is in respect to package-based build-time
> depencies and per-recipe staging.
> 
> As I see it, package-based build-time dependencies practically obsoletes
> sstate. 

This is where I think you misunderstand why sstate has been written and
what its role is.

Its a generic abstraction of taking the output from a task, saving it
away somewhere and then being able to reuse a prebuilt version of it.
There is no dependency on a package manager, package format or special
dependency formats. sstate simply looks for a prebuilt version (matching
a checksum), uses it if present, otherwise builds from "scratch".

> > I was thinking of situations like the Debian package autonamer, ie the
> > thing that causes glibc-dev to come out named "libc6-dev.ipk" or similar
> > depending on the soname of the library that was built.  It seems like
> > this would be a bit awkward to deal with if your dependencies were
> > specified purely in terms of output packages.
> 
> As OE-lite is not OE, we are currently not supporting such type of
> package renaming.  Let's leave that to Debian guys to fight with ;-)

What other features are you not supporting? Are you prepared to think
about them or is that someone else's problem?

Cheers,

Richard