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?

FWIW I was finally able to isolate one example of a change here which
isn't desired.

For qemu-helper-native, we saw do_fetch change signatures when it
shouldn't really have done. The change was:

basehash changed from ba2bcd325c42f37db9aa87567dbf0ccd217f4f12910558975a9e52e642dd426c to bd5120be022a43e6fd1273a14f0ceda3b72847308d4c4e65bfe91f9fea21683e
Variable SSTATETASKS value changed:
"do_create_package_spdx do_create_recipe_sbom do_create_recipe_spdx do_create_spdx do_deploy_source_date_epoch do_package do_package_qa [-do_package_write_deb-] do_package_write_ipk [-do_package_write_rpm-] do_packagedata do_populate_lic do_populate_sysroot do_recipe_qa"

which was probably a PACKAGE_CLASSES change in configuration triggering
it.

Whether this is the only undesired change in dependencies, I'm not sure
but we do need to track these kinds of issues down.

Cheers,

Richard