Re: a new problem with sstate

[Tom Rini <tom_rini@mentor.com>]

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?  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?

-- 
Tom Rini
Mentor Graphics Corporation