On Thu, Mar 12, 2026 at 9:58 AM Richard Purdie <[email protected]> wrote: > > On Thu, 2026-03-12 at 08:24 -0600, Joshua Watt wrote: > > On Thu, Mar 12, 2026 at 5:59 AM Richard Purdie > > <[email protected]> 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 <[email protected]> > > > > --- > > > > 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. > > Cheers, > > Richard > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#232986): https://lists.openembedded.org/g/openembedded-core/message/232986 Mute This Topic: https://lists.openembedded.org/mt/118246396/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
