Re: [OE-core] [PATCH 0/7] Remove 'extend_recipe_sysroot' from 'BB_HASHEXCLUDE_COMMON'

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2026-04-30 at 17:15 +0200, Adam Blank via
lists.openembedded.org wrote:
> > 
> > which is a lot of non-trivial change and a lot of extra data in the
> > sigdata file.
> > 
> > Do we really want all of this data to be added into every signature
> > computation?
> > 
> > Are we 100% sure that add the newly added variable dependencies are
> > "safe" and won't trigger sstate cache reuse issues?
> > 
> 
> 
> Well, obviously such increase in the visibility of dependencies is
> not a comforting or welcome thing, but let's not forget, that those
> dependencies truly are there :-)
> I'd ask the opposite question: given the extent and nature of the
> relations exposed by this change, do we want to keep wholesale hiding
> them with the current implementation?
> Or in other words, are those particular dependencies (stemming from
> 'extend_recipe_sysroot') so irrelevant for the overall signature and
> sstate management, that it is justifiable to keep ignoring them in
> such a unique way and on such a fundamental level?
> 
> Unless it is truly a desirable situation and the whole subject can be
> dismissed, what would be the recommended way to tackle it?

I'm mentioning this as I wanted to explain the delay, and why I'm
hesitant about this.

Not every piece of build information is put into the hashes and we
previously made a conscious decision that extend_recipe_sysroot and
anything hidden behind it were out of scope for the hashes. Looking at
at the list of new dependencies, I can see why we did that.

Does having these dependencies help the average user? or does it waste
space in the sigdata files and complicate the dependencies? Right now
I'm torn and I'm not sure which way we should proceed.

I should also mention that in testing, we've had sstate mismatch issues
too, e.g. 
https://autobuilder.yoctoproject.org/valkyrie/#/builders/29/builds/3747

We don't know which of the patches under test are at fault for that and
the errors are non-specific, just that sstate wasn't matching. It could
be something in this patchset, or it might be something else, we just
can't tell and don't know.

Cheers,

Richard