[RFC PATCH 1/3] Add support to add imager dependencies to BOM

[Felix Moessbauer]

Currently the imager dependencies which end up in the image are not
tracked in any BOM (e.g. the manifest file). As these cannot be
automatically derived from the IMAGER_INSTALL packages, we add a new
variable IMAGER_BOM that takes a list of binary packages which are
looked-up using dpkg-query during imaging and added to a local manifest.

Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
---
doc/user_manual.md | 1 +
meta/classes/image-tools-extension.bbclass | 7 +++++++
meta/classes/image.bbclass | 6 ++++++
3 files changed, 14 insertions(+)

diff --git a/doc/user_manual.md b/doc/user_manual.md
index 67f91973..deb66a45 100644
--- a/doc/user_manual.md
+++ b/doc/user_manual.md
@@ -454,6 +454,7 @@ Some other variables include:
- `FILESEXTRAPATHS` - The default directories BitBake uses when it processes recipes are initially defined by the FILESPATH variable. You can extend FILESPATH variable by using FILESEXTRAPATHS.
- `FILESOVERRIDES` - A subset of OVERRIDES used by the build system for creating FILESPATH. The FILESOVERRIDES variable uses overrides to automatically extend the FILESPATH variable.
- `IMAGER_INSTALL` - The list of package dependencies for an imager like wic.
+ - `IMAGER_BOM` - The list of packages that should be added to the image BOM (e.g. the bootloader). These packages must also be available in the imager rootfs.

---

diff --git a/meta/classes/image-tools-extension.bbclass b/meta/classes/image-tools-extension.bbclass
index 5e248f2e..6aa790f3 100644
--- a/meta/classes/image-tools-extension.bbclass
+++ b/meta/classes/image-tools-extension.bbclass
@@ -20,6 +20,7 @@ SCHROOT_MOUNTS += "${REPO_ISAR_DIR}/${DISTRO}:/isar-apt"

imager_run() {
local_install="${@(d.getVar("INSTALL_%s" % d.getVar("BB_CURRENTTASK")) or '').strip()}"
+ local_bom="${@(d.getVar("BOM_%s" % d.getVar("BB_CURRENTTASK")) or '').strip()}"

schroot_create_configs
insert_mounts
@@ -70,6 +71,12 @@ EOAPT

schroot -r -c ${session_id} "$@"

+ if [ -n "${local_bom}" ]; then
+ schroot -r -c ${session_id} -d / -- \
+ dpkg-query -W -f='${source:Package}|${source:Version}|${binary:Package}|${Version}\n' ${local_bom} > \
+ ${WORKDIR}/imager.manifest
+ fi
+
schroot -e -c ${session_id}

remove_mounts
diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index bd1b8552..53017963 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -184,6 +184,7 @@ python() {

imager_install = set()
imager_build_deps = set()
+ imager_bom = set()
conversion_install = set()
for bt in basetypes:
local_imager_install = set()
@@ -214,6 +215,8 @@ python() {
local_imager_install.add(dep)
for dep in (d.getVar('IMAGER_BUILD_DEPS:' + bt_clean) or '').split():
imager_build_deps.add(dep)
+ for dep in (d.getVar('IMAGER_BOM:' + bt_clean) or '').split():
+ imager_bom.add(dep)

# construct image command
image_cmd = localdata.getVar('IMAGE_CMD:' + bt_clean)
@@ -288,11 +291,14 @@ python() {
bb.build.addtask(task, 'do_image', after, d)

# set per type imager dependencies
+ d.setVar('BOM_image_%s' % bt_clean, d.getVar('IMAGER_BOM'))
+ d.appendVar('BOM_image_%s' % bt_clean, ' ' + ' '.join(sorted(imager_bom)))
d.setVar('INSTALL_image_%s' % bt_clean, d.getVar('IMAGER_INSTALL'))
d.appendVar('INSTALL_image_%s' % bt_clean, ' ' + ' '.join(sorted(local_imager_install | local_conversion_install)))
d.appendVarFlag(task, 'vardeps', ' INSTALL_image_%s' % bt_clean)

d.appendVar('IMAGER_INSTALL', ' ' + ' '.join(sorted(imager_install | conversion_install)))
+ d.appendVar('IMAGER_BOM', ' ' + ' '.join(sorted(imager_bom)))
d.appendVar('IMAGER_BUILD_DEPS', ' ' + ' '.join(sorted(imager_build_deps)))
}

--
2.51.0

[Jan Kiszka]

On 10.10.25 17:12, Felix Moessbauer wrote:
> Currently the imager dependencies which end up in the image are not
> tracked in any BOM (e.g. the manifest file). As these cannot be
> automatically derived from the IMAGER_INSTALL packages, we add a new
> variable IMAGER_BOM that takes a list of binary packages which are
> looked-up using dpkg-query during imaging and added to a local manifest.
>
> Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
> ---
> doc/user_manual.md | 1 +
> meta/classes/image-tools-extension.bbclass | 7 +++++++
> meta/classes/image.bbclass | 6 ++++++
> 3 files changed, 14 insertions(+)
>
> diff --git a/doc/user_manual.md b/doc/user_manual.md
> index 67f91973..deb66a45 100644
> --- a/doc/user_manual.md
> +++ b/doc/user_manual.md
> @@ -454,6 +454,7 @@ Some other variables include:
> - `FILESEXTRAPATHS` - The default directories BitBake uses when it processes recipes are initially defined by the FILESPATH variable. You can extend FILESPATH variable by using FILESEXTRAPATHS.
> - `FILESOVERRIDES` - A subset of OVERRIDES used by the build system for creating FILESPATH. The FILESOVERRIDES variable uses overrides to automatically extend the FILESPATH variable.
> - `IMAGER_INSTALL` - The list of package dependencies for an imager like wic.
> + - `IMAGER_BOM` - The list of packages that should be added to the image BOM (e.g. the bootloader). These packages must also be available in the imager rootfs.
>

Hmm, how about IMAGE_BUILT_USING? Would be wording-wise closer to
Debian's Built-Using.

One could even imagine having a ROOTFS_BUILT_USING as well in case evil
hacks are done via post-process commands... But maybe better exclude that.

No, this is about creating an image BOM. The imager remains a tool
outside of the distributed image.

>
> # construct image command
> image_cmd = localdata.getVar('IMAGE_CMD:' + bt_clean)
> @@ -288,11 +291,14 @@ python() {
> bb.build.addtask(task, 'do_image', after, d)
>
> # set per type imager dependencies
> + d.setVar('BOM_image_%s' % bt_clean, d.getVar('IMAGER_BOM'))
> + d.appendVar('BOM_image_%s' % bt_clean, ' ' + ' '.join(sorted(imager_bom)))

And you actually state that the imager BOM is for the image.

> d.setVar('INSTALL_image_%s' % bt_clean, d.getVar('IMAGER_INSTALL'))
> d.appendVar('INSTALL_image_%s' % bt_clean, ' ' + ' '.join(sorted(local_imager_install | local_conversion_install)))
> d.appendVarFlag(task, 'vardeps', ' INSTALL_image_%s' % bt_clean)
>
> d.appendVar('IMAGER_INSTALL', ' ' + ' '.join(sorted(imager_install | conversion_install)))
> + d.appendVar('IMAGER_BOM', ' ' + ' '.join(sorted(imager_bom)))
> d.appendVar('IMAGER_BUILD_DEPS', ' ' + ' '.join(sorted(imager_build_deps)))
> }
>

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center

[MOESSBAUER, Felix]

On Wed, 2025-10-15 at 14:57 +0200, Jan Kiszka wrote:
> On 10.10.25 17:12, Felix Moessbauer wrote:
> > Currently the imager dependencies which end up in the image are not
> > tracked in any BOM (e.g. the manifest file). As these cannot be
> > automatically derived from the IMAGER_INSTALL packages, we add a new
> > variable IMAGER_BOM that takes a list of binary packages which are
> > looked-up using dpkg-query during imaging and added to a local manifest.
> >
> > Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
> > ---
> > doc/user_manual.md | 1 +
> > meta/classes/image-tools-extension.bbclass | 7 +++++++
> > meta/classes/image.bbclass | 6 ++++++
> > 3 files changed, 14 insertions(+)
> >
> > diff --git a/doc/user_manual.md b/doc/user_manual.md
> > index 67f91973..deb66a45 100644
> > --- a/doc/user_manual.md
> > +++ b/doc/user_manual.md
> > @@ -454,6 +454,7 @@ Some other variables include:
> > - `FILESEXTRAPATHS` - The default directories BitBake uses when it processes recipes are initially defined by the FILESPATH variable. You can extend FILESPATH variable by using FILESEXTRAPATHS.
> > - `FILESOVERRIDES` - A subset of OVERRIDES used by the build system for creating FILESPATH. The FILESOVERRIDES variable uses overrides to automatically extend the FILESPATH variable.
> > - `IMAGER_INSTALL` - The list of package dependencies for an imager like wic.
> > + - `IMAGER_BOM` - The list of packages that should be added to the image BOM (e.g. the bootloader). These packages must also be available in the imager rootfs.
> >
>
> Hmm, how about IMAGE_BUILT_USING? Would be wording-wise closer to
> Debian's Built-Using.

The debian Built-Using is specific to a debian policy and references
source packages. While here we track binary packages and also the
debian policy does not apply. By that, I prefer to use a different
term.

>
> One could even imagine having a ROOTFS_BUILT_USING as well in case evil
> hacks are done via post-process commands... But maybe better exclude that.

Yes, that's not in scope for now.

I just follow the existing terminology of the imagetypes logic here.
The term "image_bom" is misleading as well, as image bom implies that
it contains a list of all packages which end up in the image (i.e. in
the .wic blob).

>
> >
> > # construct image command
> > image_cmd = localdata.getVar('IMAGE_CMD:' + bt_clean)
> > @@ -288,11 +291,14 @@ python() {
> > bb.build.addtask(task, 'do_image', after, d)
> >
> > # set per type imager dependencies
> > + d.setVar('BOM_image_%s' % bt_clean, d.getVar('IMAGER_BOM'))
> > + d.appendVar('BOM_image_%s' % bt_clean, ' ' + ' '.join(sorted(imager_bom)))
>
> And you actually state that the imager BOM is for the image.

Yes, again that follows the imagetypes naming scheme.

But I'm open for better names as long as they don't introduce yet
another terminology.

Felix

>
> > d.setVar('INSTALL_image_%s' % bt_clean, d.getVar('IMAGER_INSTALL'))
> > d.appendVar('INSTALL_image_%s' % bt_clean, ' ' + ' '.join(sorted(local_imager_install | local_conversion_install)))
> > d.appendVarFlag(task, 'vardeps', ' INSTALL_image_%s' % bt_clean)
> >
> > d.appendVar('IMAGER_INSTALL', ' ' + ' '.join(sorted(imager_install | conversion_install)))
> > + d.appendVar('IMAGER_BOM', ' ' + ' '.join(sorted(imager_bom)))
> > d.appendVar('IMAGER_BUILD_DEPS', ' ' + ' '.join(sorted(imager_build_deps)))
> > }
> >
>
> Jan
>
> --
> Siemens AG, Foundational Technologies
> Linux Expert Center

--
Siemens AG
Linux Expert Center
Friedrich-Ludwig-Bauer-Str. 3
85748 Garching, Germany