[PATCH] meta-isar/recipes-installer/bmap-tools: add Built-Using field

[srinuv...@siemens.com]

From: srinuvasan <srinuv...@siemens.com>

Add a Built-Using field to the binary package stanza in the debian/control file,
since it is not provided by the upstream source
This ensures that the original source package reference
is captured in the generated SBOM file.

During the clearance process, we need to provide the original package URL for this custom package
By including the Built-Using field in debian/control,
debsbom can record the corresponding source package information in the SBOM file.

Signed-off-by: srinuvasan <srinuv...@siemens.com>
---
meta-isar/recipes-installer/bmap-tools/bmap-tools.bb | 5 +++++
1 file changed, 5 insertions(+)

diff --git a/meta-isar/recipes-installer/bmap-tools/bmap-tools.bb b/meta-isar/recipes-installer/bmap-tools/bmap-tools.bb
index 376ab433..537e40ce 100644
--- a/meta-isar/recipes-installer/bmap-tools/bmap-tools.bb
+++ b/meta-isar/recipes-installer/bmap-tools/bmap-tools.bb
@@ -13,9 +13,14 @@ SRC_URI += "file://0001-Fix-path-parameter-passing-error-of-set_psplash_pipe.pat
file://0002-Fix-_psplash_pipe-part-was-skipped-when-_progress_fi.patch;apply=no"

do_prepare_build:append() {
+ upstream_version=$(dpkg-parsechangelog -l ${S}/debian/changelog -S Version)
+
deb_add_changelog

cd ${S}
quilt import -f ${WORKDIR}/*.patch
quilt push -a
+ # Add Built-Using section
+ grep -q '^Built-Using: bmap-tools' debian/control || \
+ sed -i "/Package: bmap-tools$/a Built-Using: bmap-tools (= ${upstream_version})" debian/control
}
--
2.39.5

[Jan Kiszka]

On 04.11.25 15:44, srinuvasan.a via isar-users wrote:
> From: srinuvasan <srinuv...@siemens.com>
>
> Add a Built-Using field to the binary package stanza in the debian/control file,
> since it is not provided by the upstream source
> This ensures that the original source package reference
> is captured in the generated SBOM file.

Is there a debian bug for that issue? Or is this only a problem for us
since we are rebuilding here?

>
> During the clearance process, we need to provide the original package URL for this custom package

Note that the term "clearing process" is not generic. We are talking
about SBOM generation, that is fairly well understood also outside.

> By including the Built-Using field in debian/control,
> debsbom can record the corresponding source package information in the SBOM file.
>
> Signed-off-by: srinuvasan <srinuv...@siemens.com>
> ---
> meta-isar/recipes-installer/bmap-tools/bmap-tools.bb | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/meta-isar/recipes-installer/bmap-tools/bmap-tools.bb b/meta-isar/recipes-installer/bmap-tools/bmap-tools.bb
> index 376ab433..537e40ce 100644
> --- a/meta-isar/recipes-installer/bmap-tools/bmap-tools.bb
> +++ b/meta-isar/recipes-installer/bmap-tools/bmap-tools.bb
> @@ -13,9 +13,14 @@ SRC_URI += "file://0001-Fix-path-parameter-passing-error-of-set_psplash_pipe.pat
> file://0002-Fix-_psplash_pipe-part-was-skipped-when-_progress_fi.patch;apply=no"
>
> do_prepare_build:append() {
> + upstream_version=$(dpkg-parsechangelog -l ${S}/debian/changelog -S Version)
> +
> deb_add_changelog
>
> cd ${S}
> quilt import -f ${WORKDIR}/*.patch
> quilt push -a
> + # Add Built-Using section
> + grep -q '^Built-Using: bmap-tools' debian/control || \
> + sed -i "/Package: bmap-tools$/a Built-Using: bmap-tools (= ${upstream_version})" debian/control
> }

Does it mean that all isar-rebuilt packages should now carry this? Then
we have more cases, and it should be established automatically, not just
case-by-case and open-coded.

Jan

--
Siemens AG, Foundational Technologies
Linux Expert Center

[Jan Kiszka]

...but I seriously doubt that this is a correct generic approach.
Built-Using has the following effect:

"This causes the Debian archive to retain the versions of the source
packages that were actually incorporated. In particular, if the versions
of the incorporated parts are updated but the incorporating binary
package is not rebuilt, the older versions of the incorporated parts
will remain in the archive in order to satisfy the license."

If we consider the superset of our fetched upstream sources plus that
that self-built packages leave behind here as the equivalent target
audience, this would cause the original sources to be stored twice
because the self-built source package not only consists of our patches.

Furthermore, if someone would extract the Debian-accumulated license
information from this, that person would also pull everything about the
upstream package twice.

So, either we stop the duplication, or we don't use a Debian control
field that is meant for different scenarios.