[PATCH 1/2] set valid maintainer in isar-ddi-definitions

[Felix Moessbauer]

The MAINTAINER field should be set to a valid and contactable maintainer
according to the debian policies. Point it to the isar ML.

Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
---
.../isar-ddi-definitions/isar-ddi-definitions_0.1.bb | 1 +
1 file changed, 1 insertion(+)

diff --git a/meta/recipes-support/isar-ddi-definitions/isar-ddi-definitions_0.1.bb b/meta/recipes-support/isar-ddi-definitions/isar-ddi-definitions_0.1.bb
index 7982f238..1fe320ec 100644
--- a/meta/recipes-support/isar-ddi-definitions/isar-ddi-definitions_0.1.bb
+++ b/meta/recipes-support/isar-ddi-definitions/isar-ddi-definitions_0.1.bb
@@ -5,6 +5,7 @@

inherit dpkg-raw

+MAINTAINER ?= "isar-users <isar-...@googlegroups.com>"
DESCRIPTION = "Definitions to generate Discoverable Disk Image"

DEBIAN_DEPENDS = "systemd, systemd-repart, cryptsetup, openssl, erofs-utils"
--
2.51.0

[Felix Moessbauer]

The debian policies require that the package maintainer is filled
with someone that can be contacted. Checks of the SBOM of various layers
have shown that often the maintainer is not explicitly set, probably
because we provide a default.

As a change of the default maintainer might create a lot of downstream
changes, we introduce a warning instead. Later on, we can remove the
default and just assert that it is set.

Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
---

meta/classes-recipe/debianize.bbclass | 10 ++++++++++
1 file changed, 10 insertions(+)

diff --git a/meta/classes-recipe/debianize.bbclass b/meta/classes-recipe/debianize.bbclass
index a629feba..a255dd28 100644
--- a/meta/classes-recipe/debianize.bbclass
+++ b/meta/classes-recipe/debianize.bbclass
@@ -25,7 +25,16 @@ MAINTAINER ??= "Unknown maintainer <unk...@example.com>"

DEBIANIZE_BUILD_DEPENDS ?= "debhelper-compat (= ${DEBIAN_COMPAT}), ${DEBIAN_BUILD_DEPENDS}"

+deb_check_maintainer() {
+ if [ -z "${MAINTAINER}" ]; then
+ bbwarn "MAINTAINER is empty. Please set a valid maintainer."
+ elif echo "${MAINTAINER}" | grep -q "@example.com"; then
+ bbwarn "MAINTAINER contains '@example.com'. Please set a valid maintainer."
+ fi
+}
+
deb_add_changelog() {
+ deb_check_maintainer
changelog_v="${CHANGELOG_V}"
timestamp="${DEBIAN_CHANGELOG_TIMESTAMP}"
if [ -f ${S}/debian/changelog ]; then
@@ -84,6 +93,7 @@ deb_create_control[vardeps] += "DEBIANIZE_BUILD_DEPENDS \
DEBIAN_RULES_REQUIRES_ROOT \
DEBIAN_STANDARDS_VERSION"
deb_create_control() {
+ deb_check_maintainer
# Add Source section
cat << EOF > ${S}/debian/control
Source: ${BPN}
--
2.51.0

[Jan Kiszka]

On 21.01.26 18:40, 'Felix Moessbauer' via isar-users wrote:
> The debian policies require that the package maintainer is filled
> with someone that can be contacted. Checks of the SBOM of various layers
> have shown that often the maintainer is not explicitly set, probably
> because we provide a default.
>
> As a change of the default maintainer might create a lot of downstream
> changes, we introduce a warning instead. Later on, we can remove the
> default and just assert that it is set.

Indeed, this is likely creating at least a lot of warning noise for
packages that are not maintained like Debian packages because they are
proprietary. I'm not yet sure it will be helpful to enforce other pseudo
addresses for those.

Maybe we should define some alternative placeholder that verbosely
documents that this packages is proprietary, and different contact
channels apply? Would still create noise in the transition.

Jan

Siemens AG, Foundational Technologies
Linux Expert Center

[MOESSBAUER, Felix]

On Wed, 2026-01-21 at 19:21 +0100, Jan Kiszka wrote:
> On 21.01.26 18:40, 'Felix Moessbauer' via isar-users wrote:
> > The debian policies require that the package maintainer is filled
> > with someone that can be contacted. Checks of the SBOM of various layers
> > have shown that often the maintainer is not explicitly set, probably
> > because we provide a default.
> >
> > As a change of the default maintainer might create a lot of downstream
> > changes, we introduce a warning instead. Later on, we can remove the
> > default and just assert that it is set.
>
> Indeed, this is likely creating at least a lot of warning noise for
> packages that are not maintained like Debian packages because they are
> proprietary. I'm not yet sure it will be helpful to enforce other pseudo
> addresses for those.

In the past this remained mostly unnoticed, as maintainer data is not
part of the manifest file and also not relevant for the license
clearing itself (still it was wrong). This changed with in introduction
of SBOMs as now this data is used downstream and by that more care
needs to be taken.

Anyways, even the isar docs request you to put in a proper string
instead of the default.

>
> Maybe we should define some alternative placeholder that verbosely
> documents that this packages is proprietary, and different contact
> channels apply? Would still create noise in the transition.

No. Just because we rebuild something does not mean it is proprietary.
Only the isar user can decide what value to put in there. If you really
want to have a setting as you just proposed, just set the MAINTAINER at
a higher level (e.g. by providing the default value in the local.conf).
This is already supported today.

Nonetheless, for SBOMs we have the garbage in -> garbage out situation.
That's why I prefer to start with good data instead of downstream
papering over.

Felix

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