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

Bruce Ashfield
2026-03-14T14:41:15Z

[-- Attachment #1: Type: text/plain, Size: 3247 bytes --]

On Sat, Mar 14, 2026 at 6:00 AM Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> 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!
>

It's probably more that I'm doing strange and niche things :)

I see your patch, I'll pull it in shortly, thanks for the fixup, I
would have taken ages to figure that out!

Bruce

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

--
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II

[-- Attachment #2: Type: text/html, Size: 4827 bytes --]