On Tue, 2026-03-10 at 12:38 -0600, Joshua Watt via lists.openembedded.org wrote: > Skips adding the install package CVE information by default. This > information grows exponentially, since it ends up be N_CVES * > N_PACKAGES. The CVE information for a given installed package can be > determined by following the "generates" link between the install package > and the recipe and looking at the CVE information for the recipe, > meaning that the CVE information is only included once in the SPDX > document. > > If users still need the legacy method of including CVE information for > each package, then then can set SPDX_PACKAGE_INCLUDE_VEX = "1" > > Signed-off-by: Joshua Watt <[email protected]> > --- > meta/classes/create-spdx-3.0.bbclass | 11 ++++++++ > meta/lib/oe/spdx30_tasks.py | 39 ++++++++++++++-------------- > meta/lib/oeqa/selftest/cases/spdx.py | 12 +++++++++ > 3 files changed, 43 insertions(+), 19 deletions(-) > > diff --git a/meta/classes/create-spdx-3.0.bbclass > b/meta/classes/create-spdx-3.0.bbclass > index c3ea95b8bc..88b7ef9f42 100644 > --- a/meta/classes/create-spdx-3.0.bbclass > +++ b/meta/classes/create-spdx-3.0.bbclass > @@ -45,6 +45,17 @@ SPDX_INCLUDE_VEX[doc] = "Controls what VEX information is > in the output. Set to > including those already fixed upstream (warning: This can be large and \ > slow)." > > +SPDX_PACKAGE_INCLUDE_VEX ?= "0" > +SPDX_PACKAGE_INCLUDE_VEX[doc] = "Link VEX information to the binary package > outputs. \ > + Normally, VEX information is only linked to the common recipe that > `generates` the \ > + binary packages, but setting this to '1' will cause it to also be linked > into the \ > + generated binary packages. This is off by default because linking the > VEX data to \ > + each package causes the SPDX output to grow very large, and the same > information \ > + can be determined by following the `generates` relationship back to the > recipe. \ > + Before recipe packages were introduced, this was the only way VEX data > was \ > + expressed; you may need to enable this if your downstream tools do not \ > + understand how to trace back to the recipe to find VEX information."
To me, removing this duplication and keeping the SPDX docs usable seems like a very sensible thing to do. Do we want/need to make it configurable? I appreciate some tools/usage may need fixing to work with this but adding configuration options like this makes it harder to use our code and also adds maintenance/testing overhead. I think I'm very much in favour of just changing and generating things like this unconditionally and if someone needs to work with it differently, they can post process the output. This goes back to my concern about the complexity of the code and configuration, I think we need to simplify and present fewer options to the user... Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#232944): https://lists.openembedded.org/g/openembedded-core/message/232944 Mute This Topic: https://lists.openembedded.org/mt/118246395/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
