[poky] a new problem with sstate

[Richard Purdie]

On Sun, 2010-11-28 at 15:12 -0700, Tom Rini wrote:
> On 11/28/2010 05:20 AM, Richard Purdie wrote:
> > On Wed, 2010-11-17 at 07:31 -0700, Tom Rini wrote:
> >> With old style packaged-staging we workaround this by doing:
> >>
> >> # We want to be certain that the scene is set for us only after it's set for
> >> # our dependencies, to avoid problems with pstage package install order.
> >> do_setscene[deptask] = "do_setscene"
> >>
> >> Can something similar be done for the sstate way of the world?
> >
> > Unfortunately not. sstate differs as the code tries to be clever about
> > the dependencies and reverse walks the dependency tree. This means that
> > if:
> >
> > A =>  B =>  C =>  D =>  E
> >
> > where "=>" means "depends on" then sstate will try and install a sstate
> > package for A, then B, then C and *stop* once it finds a match.
> >
> > This fixes one of the annoyances of packaged-staging where if you're
> > building an image and have all the ipks installed, it would still
> > install the cross toolchain.
> 
> Er, so you're saying sstate has a 3 steps back limit?  Or am I just 
> misunderstanding the example?

You're misunderstanding it :/. It could stop at any point it finds a
match, I just happened to pick three steps.

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.

>   That would sound like other things are a 
> bit hard to get done with sstate?  Or should stuff like bitbake 
> virtual/kernel ; bitbake -c menuconfig virtual/kernel ; bitbake 
> virtual/kernel (roughly...) still work?

This would all work just fine...

Cheers,

Richard