On Thu, Mar 12, 2026 at 5:55 AM Richard Purdie <[email protected]> wrote: > > 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.
Maybe, but I'm very hesitant to break any existing SPDX based CVE workflows that people may have in a LTS release, which is the only reason I added the option. I'm fine to remove this after the LTS, IMHO it's just too close to LTS release to suddenly say "sorry this is all broken for you now" > > 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 (#232971): https://lists.openembedded.org/g/openembedded-core/message/232971 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]] -=-=-=-=-=-=-=-=-=-=-=-
