Re: a new problem with sstate

[Richard Purdie <rpurdie@linux.intel.com>]

On Sun, 2010-11-28 at 16:21 -0700, Tom Rini wrote:
> > Putting it a different way, my point was that there is a "setscene" per
> > task but the setscene dependencies represent those of the "parent" task,
> > but are searched backwards compared to the normal logic. So setscene
> > tasks don't have dependencies in their own right, its linked to the
> > parent task the represent.
> 
> Right.  So, to restate the problem, in pstaging we have the problem of 
> the gcc/glibc dance not forcing themselves to be run forward in the 
> correct order, but we can fix that with some manual deps.  But in the 
> sstate of the world the problem is that we might find the wrong thing to 
> provide what we want and pick the wrong gcc or glibc sstate (and get a 
> -initial rather than finial)?

Without the change Kevin was talking about, it would always install the
gcc and glibc sstate but usually backwards, i.e. it would install glibc,
then overwrite it with glibc-initial, similarly, gcc-cross would be
overwritten with gcc-cross-intermediate which in turn would be
overwritten by gcc-cross-initial.

These things cause us pain in other ways, e.g. trying to bitbake
gcc-cross-intermediate and smashing the toolchain to pieces. or bumping
PR on glibc and glibc-initial and watching things break.

I maintain a belief that any file in the sysroots should come from one
recipe only and that we should fix the toolchain bootstrap to use
multiple sysroots as intermediate steps. Hopefully once that is done,
this problem goes away along with all the other related problems.

Cheers,

Richard