On Thu, 2023-03-09 at 14:04 +0100, Alexander Kanavin wrote:
> On Thu, 9 Mar 2023 at 13:03, Richard Purdie
> <[email protected]> wrote:
> 
> > This is a wider problem, the sysroots are often modified when things
> > are running against it as we don't require task serialisation. Instead
> > the code tries to be careful about it's manipulations. Things aren't
> > always installed/removed just from that task either, it can happen with
> > *any* task that tries to extend the sysroot (which fetch, unpack and
> > patch do as well).
> 
> Right, then I'm not sure what to do here (short of 'task-specific sysroots' 
> :-D
> 
> We can lessen the chances by serializing prepare_recipe_sysroot into
> fetch/unpack/patch/configure sequence. But it would not eliminate the
> possibility of other tasks stepping on those or each other.
> We can also make sysroot (de)population code more careful. But it
> won't solve the non-determinism.
> Making git wrapper run with python from hosttools/ solves a specific
> issue I saw, but not the broader problem.
> 
> It happened just once, so it does seem exceedingly rare.

I realised the "task specific sysroot" issue when implementing recipe
specific sysroots but I still don't know what to do about it. The
issues arising are very very rare.

The population code should avoid problems like you mentioned by
handling xxx/bin/* last. We should probably make the depopulation code
handle xxx/bin/* first which would avoid this there, too.

I've also been thinking we should have recipe specific hosttools for
quite some time but that isn't easy to get working.

For depopulation, I've wondered if bitbake should do more of this "up
front" with some changes to the taskgraph to handle it better. It would
need a new type of task which would complicate a lot of the mechanics
of the system though.

It comes back to a question of time/resources and whether anyone would
want to take on trying to make changes like this. I've slowly chipped
away at the issues but some of this is a much bigger scope of project.

https://git.yoctoproject.org/poky/commit/meta/classes/staging.bbclass?id=a819c88b875d2357751005df7594de290926ae64
was the fix for population FWIW.

Cheers,

Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#178223): 
https://lists.openembedded.org/g/openembedded-core/message/178223
Mute This Topic: https://lists.openembedded.org/mt/97493237/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to