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

Joshua Watt
2026-03-12T16:44:13Z

On Thu, Mar 12, 2026 at 10:06 AM Joshua Watt <jpewhacker@gmail.com> wrote:
>
> On Thu, Mar 12, 2026 at 9:58 AM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> >
> > 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.
>
> Right, SPDX is (supposed) to do whatever sstate does, so if it works
> for sstate it works for SPDX. The problem isn't that this code does
> the arch changing (specifically), it's that it changes the arch to an
> arbitrary one that isn't part of the normal package search order (on
> purpose), and then expects everyone to manually add in that arch when
> they need the package (which, SPDX was _not_ doing but all of the
> other SDK code obviously is). I think my proposed fix is thus correct
> and I will test it which should cover this corner case.
>
> In general, I think most packages are handled correctly because again,
> SPDX does whatever sstate does, and SPDX even respects SSTATE_ARCHS
> which is how I think other recipes would deal with a similar
> situation. However, the SDKs are different specifically because they
> expect SDK_PACKAGE_ARCH to be respected by anything dealing with the
> sdk generation code, which is what was missing in SPDX.

Hang on, I think I'm getting this confused with a different problem.....

>
> >
> > Cheers,
> >
> > Richard
> >
> >
> >
> >