Re: [OE-core] [PATCH 4/5] meta/dummy-sdk-package: Improve SDK dummy package handling

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

On Sat, 2026-03-14 at 09:47 +0000, Richard Purdie via lists.openembedded.org wrote:
> Currently, the dummy SDK packages are re-running for different SDKMACHINE values
> when they should not. The usage of allarch is broken and not triggering the right
> PACKAGE_ARCH value due to the deferred nature of nativesdk. This was probably
> broken when we switched to add deferred classes.
> 
> To try and make this all more explict and less prone to breakage, switch to calling
> oe.utils.make_arch_independent() directly.
> 
> Add the 'special' package architecture values to SSTATE_ARCHS so the system cna properly
> track them.
> 
> Remove the pointless tasks we don't need from the dummy recipes, mark the packagedata
> as machine independent and then remove from the conflict list in sstate.bbclass.
> 
> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

This patch fixes real issues with the way the dummy recipes are
currently being handled. Unfortunately this change still isn't without
issues, this is shown by the failure in meta-virtualization it
introduces. It is starting to feel like I'm somehow targeting Bruce
recently, sorry!

The failure this patchset triggers in meta-virtualization is here:

https://autobuilder.yoctoproject.org/valkyrie/#/builders/89/builds/3215

The reason is that it is doing this:

recipes-core/meta/container-dummy-provides.bb:require recipes-core/meta/dummy-sdk-package.inc

which is fine, I hadn't realised layers were using that but it should
be something you can do. At first glance, the fix looks easy, just add:

DUMMYSDK_PKGDATA_VARNAME = "PKGDATA_DIR"
DUMMYSDK_EXTRASTAMP_VARNAME = "MACHINE"

to the recipe. That doesn't account for the sstate.bbclass and
sstatesig.py changes this patch is making though.

I've never been happy at having to add these individually to the "feed"
lists in the first place and another layer trying to do this
illustrates why.

I'm at a bit of a loss on what to do from here. Options could be:

a) move the recipe to core and add another entry to
sstate.bbclass/sstatesig.py . That doesn't help it anyone else does
this

b) Create some layer.conf variables which allow these to be
defined/added generically. That would need careful manipulation of the
hash variable dependencies to stop things rebuilding like crazy.

c) Find a way for the core not to need this list hardcoded. That would
be nicer and removes what looks like a horrible scaling issue we have
right now I don't know how to do that.

d) Something else

I'm open to ideas, these changes are needed to unblock the spdx
changes.

Cheers,

Richard