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

Joshua Watt
2026-03-12T18:02:22Z

On Thu, Mar 12, 2026 at 10:43 AM Joshua Watt <jpewhacker@gmail.com> wrote:
>
> 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.....

Ok, I remember this one correctly now (who needs AI to
hallucinate....). I think the correct thing to do here is to add:

do_create_recipe_spdx[vardeps] += "PACKAGE_ARCH"

because it's not rebuilding when this recipe changes PACKAGE_ARCH. The
other SPDX tasks are because of an implicit dependency on PACKAGE_ARCH
that re-triggers them. In the back of my mind I seem to recall we
maybe didn't want to do this for some reason, but PACKAGE_ARCH isn't
in BB_*_IGNORE_VARS so maybe I'm just mis-remembering.

Anyway, if this fix seems correct I'll make it.

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