[PATCH 0/2] handle DPKG_ARCH=all case for transitive deps

[Felix Moessbauer]

This series fixes an issue with DPKG_ARCH=all packages that have
dependencies to other DPKG_ARCH=all packages. Hereby, the transitive
packages were built for the wrong architecture. The issue became
apparent when testing the SBOM series by Christoph, which builds
packages to be used during the ISAR build (not for the final target).

While fixing this, another issue surfaced where files are missing in
dpkg-raw packages.

Best regards,
Felix

Felix Moessbauer (2):
dpkg-raw: add files to source package
handle DPKG_ARCH=all case for transitive deps

meta/classes/dpkg-raw.bbclass | 4 ++--
meta/classes/multiarch.bbclass | 18 +++++++++++++++++-
2 files changed, 19 insertions(+), 3 deletions(-)

--
2.50.1

[Felix Moessbauer]

In dpkg-raw, the user can place files in ${D} which are then installed
into the resulting binary package. Hereby, ${D} is a directory outside
of ${S} (since b19cd25) to not interfere with other data added to ${S}.
However, by that the files are not added to the source package. This
remained unnoticed, as the directory dh_install installs from is set
to absolute path, hence the installed files actually came from the
absolute path and not from the extracted source package. In case of
${PN} == ${BPN}, this path was always there as it has been created by
previous tasks. However, with the switch in 2ca3a7e5 to only build the
source package once, the path is not always there.

We fix this by adding the files to the source package (under image) and
install from a relative base. We further use a sub-path (image) in ${S}
as a temporary location to not run into the issue solved in b19cd25.

Fixes: 2ca3a7e5 ("dpkg-source: Build source package only once")
Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
---
meta/classes/dpkg-raw.bbclass | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes/dpkg-raw.bbclass b/meta/classes/dpkg-raw.bbclass
index a7bf204a..d4cb7d8a 100644
--- a/meta/classes/dpkg-raw.bbclass
+++ b/meta/classes/dpkg-raw.bbclass
@@ -5,7 +5,7 @@

inherit dpkg

-D = "${WORKDIR}/image"
+D = "${S}/image"

# Default to creating a binary-indep package
DPKG_ARCH ??= "all"
@@ -30,6 +30,6 @@ do_prepare_build() {
cat <<EOF >> ${S}/debian/rules

override_dh_install:
- dh_install --sourcedir=${PP}/image
+ dh_install --sourcedir=image
EOF
}
--
2.50.1

[Felix Moessbauer]

Arch=all packages might build depend on other arch=all packages, hence we
need to correctly model the dependency chain. Otherwise the transitive
dependencies are built for the distro arch instead of the native arch.

We implement this by dispatching the non-native variant of DPKG_ARCH=all
packages to the -native variant by adding a dependency. We further
replace the non-native do_deploy_dep task with a noop to preserve the
dependency chain.

Co-developed-by: Adriaan Schmidt <adriaan...@siemens.com>

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

meta/classes/multiarch.bbclass | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/meta/classes/multiarch.bbclass b/meta/classes/multiarch.bbclass
index babdfbd4..c2bba21f 100644
--- a/meta/classes/multiarch.bbclass
+++ b/meta/classes/multiarch.bbclass
@@ -29,7 +29,11 @@ python() {
d.appendVar('BBCLASSEXTEND', ' compat')

# build native separately only when it differs from the target variant
- if not archIsAll and archDiffers:
+ # We must not short-circuit for DPKG_ARCH=all packages, as they might
+ # have transitive dependencies which need to be built for -native.
+ # This special handling for DPKG_ARCH=all packages is left to the
+ # multiarch_virtclass_handler
+ if archDiffers:
d.appendVar('BBCLASSEXTEND', ' native')
else:
extend_provides(pn, 'native', d)
@@ -86,6 +90,8 @@ python multiarch_virtclass_handler() {
d.setVar(var, ' '.join(multiarch_var))

pn = e.data.getVar('PN')
+ archDiffers = d.getVar('HOST_ARCH') != d.getVar('DISTRO_ARCH')
+ archIsAll = d.getVar('DPKG_ARCH') == 'all'
if pn.endswith('-compat'):
e.data.setVar('BPN', pn[:-len('-compat')])
e.data.appendVar('OVERRIDES', ':class-compat')
@@ -96,6 +102,16 @@ python multiarch_virtclass_handler() {
e.data.appendVar('OVERRIDES', ':class-native')
fixup_pn_in_vars(e.data)
fixup_depends('-native', e.data)
+ elif archIsAll and archDiffers:
+ # Arch=all packages might build depend on other arch=all packages,
+ # hence we need to correctly model the dependency chain.
+ # We implement this by dispatching the non-native variant to the -native
+ # variant by adding a dependency. We further replace the non-native
+ # do_deploy_dep task with a noop to preserve the dependency chain.
+ e.data.setVar('do_deploy_deb', '')
+ bb.build.deltask('deploy_deb', e.data)
+ bb.build.addtask('deploy_deb', 'do_build', '', e.data)
+ e.data.setVarFlag('do_deploy_deb', 'depends', f'{pn}-native:do_deploy_deb')
}
addhandler multiarch_virtclass_handler
multiarch_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
--
2.50.1

[Andreas Naumann]

Hi Felix, all,

Am 20.08.25 um 14:41 schrieb 'Felix Moessbauer' via isar-users:

> Arch=all packages might build depend on other arch=all packages, hence we
> need to correctly model the dependency chain. Otherwise the transitive
> dependencies are built for the distro arch instead of the native arch.
>
> We implement this by dispatching the non-native variant of DPKG_ARCH=all
> packages to the -native variant by adding a dependency. We further
> replace the non-native do_deploy_dep task with a noop to preserve the
> dependency chain.
>
> Co-developed-by: Adriaan Schmidt <adriaan...@siemens.com>
> Signed-off-by: Felix Moessbauer <felix.mo...@siemens.com>
> ---
> meta/classes/multiarch.bbclass | 18 +++++++++++++++++-
> 1 file changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/meta/classes/multiarch.bbclass b/meta/classes/multiarch.bbclass
> index babdfbd4..c2bba21f 100644
> --- a/meta/classes/multiarch.bbclass
> +++ b/meta/classes/multiarch.bbclass
> @@ -29,7 +29,11 @@ python() {
> d.appendVar('BBCLASSEXTEND', ' compat')
>
> # build native separately only when it differs from the target variant
> - if not archIsAll and archDiffers:
> + # We must not short-circuit for DPKG_ARCH=all packages, as they might
> + # have transitive dependencies which need to be built for -native.

Funny enough i suspected to have the same problem yesterday, but it
turned out to
be different: When a package is single architecture only, e.g. arm64, it
should not be
extended as native if HOST_ARCH is amd64.

So I added a check to BBCLASSEXTEND only if DPKG_ARCH != HOST_ARCH.

> + # This special handling for DPKG_ARCH=all packages is left to the
> + # multiarch_virtclass_handler
> + if archDiffers:
> d.appendVar('BBCLASSEXTEND', ' native')

Now, seeing your patch to remove the not-"all" case also, I wonder if
that could be used
as the sole check before BBCLASSEXTEND. Like e.g.
archIsNative = d.getVar('DPKG_ARCH') == d.getVar('HOST_ARCH')
if isNative:

   d.appendVar('BBCLASSEXTEND', ' native')
> else:
> extend_provides(pn, 'native', d)

but now I wonder what the extend_provides is needed for. If HOST_ARCH ==
DISTRO_ARCH, what's
the use of providing a native variant?

But back to your Patch: Is it possible that -compat "all" packages also have
dependencies on other "all" packages, which in turn have dependencies on
architecture specific packages?

regards,
Andreas

Andreas Naumann

emlix GmbH
Headquarters: Berliner Str. 12, 37073 Goettingen, Germany
Phone +49 (0)551 30664-0, e-mail in...@emlix.com
District Court of Goettingen, Registry Number HR B 3160
Managing Directors: Heike Jordan, Dr. Uwe Kracke
VAT ID No. DE 205 198 055
Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
Office Bonn: Bachstr. 6, 53115 Bonn, Germany
http://www.emlix.com

[MOESSBAUER, Felix]

Good catch. This case is currently not handled. But I would like to
have it in a separate patch, as it tackles another issue.

>
> > + # This special handling for DPKG_ARCH=all packages is left to the
> > + # multiarch_virtclass_handler
> > + if archDiffers:
> > d.appendVar('BBCLASSEXTEND', ' native')
> Now, seeing your patch to remove the not-"all" case also, I wonder if
> that could be used
> as the sole check before BBCLASSEXTEND. Like e.g.
> archIsNative = d.getVar('DPKG_ARCH') == d.getVar('HOST_ARCH')
> if isNative:
>    d.appendVar('BBCLASSEXTEND', ' native')
> > else:
> > extend_provides(pn, 'native', d)
>
> but now I wonder what the extend_provides is needed for. If HOST_ARCH ==
> DISTRO_ARCH, what's
> the use of providing a native variant?

If we are building for the native arch, we can just add the -native
variants to the PROVIDES, so dependencies of packages depending
explicitly on <foo>-native can be resolved (without the need for extra
recipe variants).

>
> But back to your Patch: Is it possible that -compat "all" packages also have
> dependencies on other "all" packages, which in turn have dependencies on
> architecture specific packages?

Good question. In general, package dependencies are resolved for the
native architecture (or the requested one). AFAIK this selection is
propagated down the dependency tree. By that, A:i386 -> B:all -> C:x
should always resolve C as either :all or i386 (except if there is a
explicit cross-arch dependency specifier like :any, which we don't
model in bitbake). Anyways, The A:i386 -> B:all -> C:i386 chain should
already be resolved correctly with this patch.

Tested by's are welcome :)

Felix

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

[Andreas Naumann]

Am 11.09.25 um 12:20 schrieb MOESSBAUER, Felix:

I thought it's possible to make the nesting of if-clauses easier that
way, but after some more thought and fiddling... unfortunately it's the
opposite. So yes, separate patch.

>
>>> + # This special handling for DPKG_ARCH=all packages is left to the
>>> + # multiarch_virtclass_handler
>>> + if archDiffers:
>>> d.appendVar('BBCLASSEXTEND', ' native')
>> Now, seeing your patch to remove the not-"all" case also, I wonder if
>> that could be used
>> as the sole check before BBCLASSEXTEND. Like e.g.
>> archIsNative = d.getVar('DPKG_ARCH') == d.getVar('HOST_ARCH')
>> if isNative:
>>    d.appendVar('BBCLASSEXTEND', ' native')
>>> else:
>>> extend_provides(pn, 'native', d)
>> but now I wonder what the extend_provides is needed for. If HOST_ARCH ==
>> DISTRO_ARCH, what's
>> the use of providing a native variant?
> If we are building for the native arch, we can just add the -native
> variants to the PROVIDES, so dependencies of packages depending
> explicitly on <foo>-native can be resolved (without the need for extra
> recipe variants).

I understand that its a simpler solution in that case. But, maybe I'm not
seeing the obvious, what would require a -native package then? If
target-arch
is host-arch, why would anything else than the base package be in any
dependency chain?

>
>> But back to your Patch: Is it possible that -compat "all" packages also have
>> dependencies on other "all" packages, which in turn have dependencies on
>> architecture specific packages?
> Good question. In general, package dependencies are resolved for the
> native architecture (or the requested one). AFAIK this selection is
> propagated down the dependency tree. By that, A:i386 -> B:all -> C:x
> should always resolve C as either :all or i386 (except if there is a
> explicit cross-arch dependency specifier like :any, which we don't
> model in bitbake). Anyways, The A:i386 -> B:all -> C:i386 chain should
> already be resolved correctly with this patch.

The patch doesnt change that -compat is "short-circuited" when
archIsAll, doesnt it?
Or maybe I dont fully understand how the code works yet.

>
> Tested by's are welcome :)

I'm working with it and keep an eye on it.

regards,
Andreas

[MOESSBAUER, Felix]

Consider the case where you have a documentation generator in your
dependency chain. This should always run in the native arch. In Debian,
this build dependency would be annotated with <foo>:any. In ISAR, you
need to annotate it with -native, to ensure that always the native
version is built, no matter what is DISTRO_ARCH.

>
> >
> > > But back to your Patch: Is it possible that -compat "all" packages also have
> > > dependencies on other "all" packages, which in turn have dependencies on
> > > architecture specific packages?
> > Good question. In general, package dependencies are resolved for the
> > native architecture (or the requested one). AFAIK this selection is
> > propagated down the dependency tree. By that, A:i386 -> B:all -> C:x
> > should always resolve C as either :all or i386 (except if there is a
> > explicit cross-arch dependency specifier like :any, which we don't
> > model in bitbake). Anyways, The A:i386 -> B:all -> C:i386 chain should
> > already be resolved correctly with this patch.
> The patch doesnt change that -compat is "short-circuited" when
> archIsAll, doesnt it?
> Or maybe I dont fully understand how the code works yet.
> >
> > Tested by's are welcome :)
>
> I'm working with it and keep an eye on it.

Thanks!

If there are no other comments, this patchset is ready to be merged.

Felix

[Andreas Naumann]

Hi Felix,

Am 20.08.25 um 14:41 schrieb 'Felix Moessbauer' via isar-users:

I have now done some more testing and unfortunately find that this
causes failures when building the -native variant of some dpkg-raw
packages we have. We use them for certain config files and they are
intended for the target. I dont know why exactly they fail and I'm sure
this could be fixed, but actually there is no need to build those
packages in the native environment. So I'm somewhat surprised to see
that and could image that this causes confusion for others that dont
know about the "all" intricacies as well.

Another observation that I see is that dpkg-prebuilt "any" packages,
which are probably in the dependency chain of an "all" package, now are
always also built as -native, even though they are needed for the target
only.

best,
Andras

> }
> addhandler multiarch_virtclass_handler
> multiarch_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"

--

[MOESSBAUER, Felix]

Hi, do you have an example for such a package? Just to be clear: There
is no "native" variant of a dpkg-raw package. The dpkg-raw packages are
always build on the host architecture (in bitbake terms) and of Debian
arch=all.

> We use them for certain config files and they are
> intended for the target.
>

Do these configs contain data that is not the same on all
architectures? If so, DPKG_ARCH="all" is wrong.

> I dont know why exactly they fail and I'm sure
> this could be fixed, but actually there is no need to build those
> packages in the native environment.
>

There is need to do so, as otherwise we emulate the build process which
is super slow.

> So I'm somewhat surprised to see
> that and could image that this causes confusion for others that dont
> know about the "all" intricacies as well.

Probably, but in the end we are building a debian system and by that
the users should be aware of the debian architecture specifiers.

>
> Another observation that I see is that dpkg-prebuilt "any" packages,
> which are probably in the dependency chain of an "all" package, now are
> always also built as -native, even though they are needed for the target
> only.

Same here, even if bitbake tells you that they are build as "-native",
there is no difference in the output, as the binary is simply copied.

Best regards,
Felix

>
> best,
> Andras
>
> > }
> > addhandler multiarch_virtclass_handler
> > multiarch_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
>
> --
> Andreas Naumann
>
> emlix GmbH
> Headquarters: Berliner Str. 12, 37073 Goettingen, Germany
> Phone +49 (0)551 30664-0, e-mail in...@emlix.com
> District Court of Goettingen, Registry Number HR B 3160
> Managing Directors: Heike Jordan, Dr. Uwe Kracke
> VAT ID No. DE 205 198 055
> Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
> Office Bonn: Bachstr. 6, 53115 Bonn, Germany
> http://www.emlix.com

[Andreas Naumann]

Hi Felix, all

Am 16.09.25 um 09:16 schrieb MOESSBAUER, Felix:

After some debugging, it seems to be a combination of your patch and
"2ca3a7e dpkg-source: Build source package only once". There is no
problem building our dpkg-raw packages explicitly in the non-native
form, e.g. in the host environment for the target arch.
But through your patch, the package also runs as -native, which then
triggers a problem with 2ca3a7e.

... I only now discover that the other part of your patchset "dpkg-raw:
add files to source package" fixes this. Ok.

However, because of this I went digging on why you introduced the patch.
And I wonder why sbom-chroot doesn't just depend on
python3-debsbom-native directly? (Which still breaks as long as 2ca3a7e
sets the dependency on a function of the non-native package).

>> I dont know why exactly they fail and I'm sure
>> this could be fixed, but actually there is no need to build those
>> packages in the native environment.
>>
> There is need to do so, as otherwise we emulate the build process which
> is super slow.

Yes you're right. I meant there is no need to build them *for* the
native architecture.

>> So I'm somewhat surprised to see
>> that and could image that this causes confusion for others that dont
>> know about the "all" intricacies as well.
> Probably, but in the end we are building a debian system and by that
> the users should be aware of the debian architecture specifiers.

Yes sure, they were new to me, but no problem, they are not that
complicated.

But when I deliberately build -native packages (which I assume to be a
valid use case according to the doc), and somehow the buildsystem goes
back and forth running functions from the native and the base package,
it's difficult to follow why that would be necessary. It doesnt make for
ease of debugging when working on new packages either.

For the use cases I have in sight right now it would be fine if a
package build breaks because it cannot be done cross-architecture. I'd
hope to being able to fix this by either improving the package or making
sure to call it -native only. But if that's not what the expectation is
for Debian Crossbuilding I'm eager to learn.

best regards,
Andreas

>> Another observation that I see is that dpkg-prebuilt "any" packages,
>> which are probably in the dependency chain of an "all" package, now are
>> always also built as -native, even though they are needed for the target
>> only.
> Same here, even if bitbake tells you that they are build as "-native",
> there is no difference in the output, as the binary is simply copied.
>
> Best regards,
> Felix
>
>> best,
>> Andras
>>
>>> }
>>> addhandler multiarch_virtclass_handler
>>> multiarch_virtclass_handler[eventmask] = "bb.event.RecipePreFinalise"
>> --
>> Andreas Naumann
>>
>> emlix GmbH
>> Headquarters: Berliner Str. 12, 37073 Goettingen, Germany

>> Phone +49 (0)551 30664-0, e-mai...@emlix.com

>> District Court of Goettingen, Registry Number HR B 3160
>> Managing Directors: Heike Jordan, Dr. Uwe Kracke
>> VAT ID No. DE 205 198 055
>> Office Berlin: Panoramastr. 1, 10178 Berlin, Germany
>> Office Bonn: Bachstr. 6, 53115 Bonn, Germany
>> http://www.emlix.com

--

Andreas Naumann

emlix GmbH
Headquarters: Berliner Str. 12, 37073 Goettingen, Germany

Phone +49 (0)551 30664-0, e-mai...@emlix.com