Re: [OE-core][PATCH v6 10/15] dummy-sdk-package: Disable SPDX

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

On Thu, 2026-03-12 at 08:24 -0600, Joshua Watt wrote:
> On Thu, Mar 12, 2026 at 5:59 AM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > 
> > On Tue, 2026-03-10 at 12:38 -0600, Joshua Watt via lists.openembedded.org wrote:
> > > The dummy SDK packages do not need SPDX support, and since they play
> > > some games with allarch that cause problems, it's simplest to disable
> > > their SPDX output.
> > > 
> > > Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
> > > ---
> > >  meta/recipes-core/meta/dummy-sdk-package.inc | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/meta/recipes-core/meta/dummy-sdk-package.inc b/meta/recipes-core/meta/dummy-sdk-package.inc
> > > index bf453cac9b..71e788b0b9 100644
> > > --- a/meta/recipes-core/meta/dummy-sdk-package.inc
> > > +++ b/meta/recipes-core/meta/dummy-sdk-package.inc
> > > @@ -4,6 +4,7 @@ LICENSE = "MIT"
> > >  PACKAGE_ARCH = "all"
> > > 
> > >  inherit allarch
> > > +inherit nospdx
> > > 
> > >  INHIBIT_DEFAULT_DEPS = "1"
> > 
> > I know why you did this, but after thinking about this, I'm worried and
> > I'm not sure this is the right move.
> > 
> > The SDK dummy packages are "odd" but they are actual package files that
> > are generated and would be present in manifests and as such, if they're
> > missing from the SPDX manifests and docs, this is going to raise
> > questions. I appreciate they don't have content and their main use is
> > their 'provides'.
> > 
> > Taking a step back, we do support generic/multiple levels of package
> > arch and since we support that, the SPDX code does need to handle that
> > too. I'm therefore starting to worry that SPDX can't cope with the
> > multiple package levels. Can you remind me what the issue is with the
> > "all" arch here?
> 
> The problem is specifically the anonymous python that does:
> 
>     d.setVar('PACKAGE_ARCH', '${DUMMYARCH}')
> 
> Which seems specifically intended to bypass the allarch logic in a
> weird way. It's specifically doing this to put the package in a place
> no-one can find it (this includes SPDX); I didn't think it provided
> much value hence disabling it, but looking closer, I think we can do:
> 
> SSTATE_MULTILIB_SSTATE_ARCHS:append = " ${SDK_PACKAGE_ARCH}"
> 
> in create-spdx-sdk-3.0.bbclass and that should fix it. I'll try it.

That code was to put these packages into their own separate feed.
Specifically:

meta/recipes-core/meta/nativesdk-buildtools-perl-dummy.bb:DUMMYARCH = "buildtools-dummy-${SDKPKGSUFFIX}"
meta/recipes-core/meta/nativesdk-sdk-provides-dummy.bb:DUMMYARCH = "sdk-provides-dummy-${SDKPKGSUFFIX}"
meta/recipes-core/meta/dummy-sdk-package.inc:    d.setVar('PACKAGE_ARCH', '${DUMMYARCH}')
meta/recipes-core/meta/target-sdk-provides-dummy.bb:DUMMYARCH = "sdk-provides-dummy-target"

so there are separate package feeds being created and then the SDK code
can select which package feeds it wants to use for a given
configuration/recipe.

That isn't to bypass allarch but just to customise the end package feed
naming and allow different forms of SDK to be built by bringing in the
different package combinations.

My worry is that the SPDX code isn't going to handle the scenario where
PACKAGE_ARCH is changed (for example for a specialist graphics stack)
and that one of our general features will be lost.

Cheers,

Richard