On Thu, Mar 12, 2026 at 10:06 AM Joshua Watt <[email protected]> wrote: > > 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.
Hang on, I think I'm getting this confused with a different problem..... > > > > > Cheers, > > > > Richard > > > > > > > >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#232997): https://lists.openembedded.org/g/openembedded-core/message/232997 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]] -=-=-=-=-=-=-=-=-=-=-=-
