[poky] a new problem with sstate

[Tom Rini]

On 11/28/2010 04:06 PM, Richard Purdie wrote:
> 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.

Figured.

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

-- 
Tom Rini
Mentor Graphics Corporation