From: stondo@gmail.com
To: docs@lists.yoctoproject.org
Cc: antonin.godard@bootlin.com, peter.marko@siemens.com,
adrian.freihofer@siemens.com, stefano.tondo.ext@siemens.com
Subject: [PATCH v5] ref-manual: Document SPDX 3.0.1 variables
Date: Tue, 25 Nov 2025 11:01:14 +0100 [thread overview]
Message-ID: <20251125100114.24243-1-stondo@gmail.com> (raw)
From: Stefano Tondo <stefano.tondo.ext@siemens.com>
Add comprehensive documentation for SPDX-related variables in the
Yocto reference manual. This includes documenting previously
undocumented variables and updating existing documentation with
SPDX 3.0.1 specific information.
New variables documented:
- SPDX_LICENSES: Path to SPDX license identifier mapping file
- SPDX_MULTILIB_SSTATE_ARCHS: Architecture list for dependency collection
- SPDX_UUID_NAMESPACE: Namespace for UUID generation in SPDX documents
Updated existing variables with SPDX 3.0.1 data:
- SPDX_INCLUDE_SOURCES: Added SPDX 3.0.1 distributed architecture info
(rootfs SBOM: 5-6 MB regardless of source inclusion settings)
- SPDX_INCLUDE_COMPILED_SOURCES: Updated with SPDX 3.0.1 format information
Key architectural difference in SPDX 3.0.1:
The rootfs SBOM (tmp/deploy/images/) contains only relationships and metadata,
while per-package SPDX documents are stored in tmp/deploy/spdx/. This
distributed approach means source inclusion settings have minimal impact on
rootfs SBOM size, unlike the monolithic SPDX 2.2 format.
Tested with core-image-minimal on qemux86-64 (Yocto 5.3).
Signed-off-by: Stefano Tondo <stefano.tondo.ext@siemens.com>
---
documentation/ref-manual/variables.rst | 72 +++++++++++++++++++++++---
1 file changed, 66 insertions(+), 6 deletions(-)
diff --git a/documentation/ref-manual/variables.rst b/documentation/ref-manual/variables.rst
index f0a99aafb..0f5ab2d5e 100644
--- a/documentation/ref-manual/variables.rst
+++ b/documentation/ref-manual/variables.rst
@@ -9000,10 +9000,21 @@ system and gives an overview of their function and contents.
SPDX_INCLUDE_COMPILED_SOURCES = "1"
- According to our tests, building ``core-image-minimal`` for the
- ``qemux86-64`` machine, enabling this option compared with the
- :term:`SPDX_INCLUDE_SOURCES` reduces the size of the ``tmp/deploy/spdx``
- directory from 2GB to 1.6GB.
+ According to our tests on release 4.1 "langdale" (SPDX 2.2 format), building
+ ``core-image-minimal`` for the ``qemux86-64`` machine, enabling this
+ option compared with the :term:`SPDX_INCLUDE_SOURCES` reduced the size
+ of the ``tmp/deploy/spdx`` directory from 2GB to 1.6GB.
+
+ With SPDX 3.0.1 JSON-LD format, the uncompressed image SBOM file
+ (``core-image-minimal-qemux86-64.rootfs.spdx.json``) is approximately
+ **260 MB without sources** (``SPDX_INCLUDE_SOURCES = "0"``), and increases to
+ **~2.5-2.6 GB when sources are included** (either ``SPDX_INCLUDE_SOURCES = "1"``
+ or ``SPDX_INCLUDE_COMPILED_SOURCES = "1"``). This represents approximately
+ a **10x size increase** when including source files.
+
+ Note: SPDX 3.0.1 JSON-LD files are not compressed by default, unlike the
+ tar.zst format used in SPDX 2.2. Compression (e.g. zstd) can significantly
+ reduce the file size.
:term:`SPDX_INCLUDE_SOURCES`
This option allows to add a description of the source files used to build
@@ -9017,8 +9028,8 @@ system and gives an overview of their function and contents.
SPDX_INCLUDE_SOURCES = "1"
- According to our tests on release 4.1 "langdale", building
- ``core-image-minimal`` for the ``qemux86-64`` machine, enabling
+ According to our tests on release 4.1 "langdale" (SPDX 2.2 format),
+ building ``core-image-minimal`` for the ``qemux86-64`` machine, enabling
this option multiplied the total size of the ``tmp/deploy/spdx``
directory by a factor of 3 (+291 MiB for this image),
and the size of the ``IMAGE-MACHINE.spdx.tar.zst`` in
@@ -9026,6 +9037,42 @@ system and gives an overview of their function and contents.
image), compared to just using the :ref:`ref-classes-create-spdx` class
with no option.
+ With SPDX 3.0.1 JSON-LD format, the uncompressed image SBOM file
+ (``core-image-minimal-qemux86-64.rootfs.spdx.json``) is approximately
+ **260 MB without sources** (default: ``SPDX_INCLUDE_SOURCES = "0"``),
+ and increases to **~2.5-2.6 GB when sources are included**
+ (``SPDX_INCLUDE_SOURCES = "1"``). This represents approximately a
+ **10x size increase** when including source files.
+
+ Note: SPDX 3.0.1 JSON-LD files are not compressed by default, unlike the
+ tar.zst format used in SPDX 2.2. Compression (e.g. zstd) can significantly
+ reduce the file size.
+
+ :term:`SPDX_LICENSES`
+ Path to the JSON file containing SPDX license identifier mappings. This
+ file maps common license names to official SPDX license identifiers used
+ during SBOM generation.
+
+ The default value is::
+
+ SPDX_LICENSES = "${COREBASE}/meta/files/spdx-licenses.json"
+
+ You can override this variable to use a custom license mapping file if
+ your organization uses different license naming conventions.
+
+ :term:`SPDX_MULTILIB_SSTATE_ARCHS`
+ The list of sstate architectures to consider when collecting SPDX
+ dependencies. This includes multilib architectures when multilib is
+ enabled.
+
+ The default value is::
+
+ SPDX_MULTILIB_SSTATE_ARCHS = "${SSTATE_ARCHS}"
+
+ This variable is used internally by the SPDX generation classes to
+ ensure all relevant dependencies are included in the SBOM, regardless
+ of whether multilib is enabled or not.
+
:term:`SPDX_NAMESPACE_PREFIX`
This option could be used in order to change the prefix of ``spdxDocument``
and the prefix of ``documentNamespace``. It is set by default to
@@ -9053,6 +9100,19 @@ system and gives an overview of their function and contents.
this option is recommended if you want to inspect the SPDX
output files with a text editor.
+ :term:`SPDX_UUID_NAMESPACE`
+ The namespace used for generating UUIDs in SPDX documents. This should
+ be a domain name or unique identifier for your organization to ensure
+ globally unique SPDX IDs across different builds and organizations.
+
+ The default value is::
+
+ SPDX_UUID_NAMESPACE = "sbom.openembedded.org"
+
+ You can override this variable to use your organization's domain::
+
+ SPDX_UUID_NAMESPACE = "sbom.example.com"
+
:term:`SPDXLICENSEMAP`
Maps commonly used license names to their SPDX counterparts found in
``meta/files/common-licenses/``. For the default :term:`SPDXLICENSEMAP`
--
2.51.1
next reply other threads:[~2025-11-25 10:01 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-25 10:01 stondo [this message]
2025-11-25 13:12 ` [PATCH v5] ref-manual: Document SPDX 3.0.1 variables Antonin Godard
[not found] ` <AS4PR10MB51507872845B518128E53BFEACD1A@AS4PR10MB5150.EURPRD10.PROD.OUTLOOK.COM>
2025-11-26 12:24 ` Antonin Godard
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251125100114.24243-1-stondo@gmail.com \
--to=stondo@gmail.com \
--cc=adrian.freihofer@siemens.com \
--cc=antonin.godard@bootlin.com \
--cc=docs@lists.yoctoproject.org \
--cc=peter.marko@siemens.com \
--cc=stefano.tondo.ext@siemens.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.