On 10/6/26 5:19 PM, Juan Manuel Méndez Rey wrote:
Revisiting this with a concrete case. Debian's chromium package needs a foreign
architecture Build-Depends on armhf, to cross-host its linker as a genuine
64-bit process. This is the only approach that has produced a working chrome
binary on armhf, after testing the alternatives. Two independent MRs hit the
same wall, both validated end to end with real armhf sbuilds:
https://salsa.debian.org/chromium-team/chromium/-/merge_requests/44
(cross-hosted mold: mold:amd64 [armhf] | mold:arm64 [armhf])
https://salsa.debian.org/chromium-team/chromium/-/merge_requests/45
(cross-hosted lld-22: lld-22:arm64 [armhf])
On buildd.debian.org the armhf buildds are the arm64 machines, so the foreign
architecture that matters there is arm64.
Same problem the bug was filed for in 2014, cross-toolchain packages needing both host
and target architecture dependencies. The current archive has zero packages using the
pkg:arch syntax though, current cross-gcc packages avoid it with native
"-cross" suffixed packages instead. These two MRs may be the first concrete
case for it since then.
What changed since 2015: dose-builddebcheck now has a --deb-foreign-archs
option that did not exist when this bug was filed. Tested directly against the
real binary (7.0.0-8+b1): a native-only Packages file leaves mold:amd64
unsatisfiable, adding the foreign Packages file with --deb-foreign-archs=amd64
resolves it.
Two small patches, one per layer:
1. bin/wanna-build, wb_dose_builddebcheck(): collect the distinct architectures
across the given Packages files, treat the one matching --arch as native and
the rest as --deb-foreign-archs. Each file still has to be single-arch, and
--arch still has to match one of them. Backward compatible, native-only input
generates the same command line as today, including the production shape with
the derived build-essential file.
2. triggers/common: after the per-architecture Packages files are built, write
Packages.SUITE.ARCH.foreign for each architecture (the Packages file of its
foreign architecture, empty where there is none) and pass it in the dose group of
the three merge-v3 invocations. The mapping is one case statement, armhf ->
arm64 for now.
Validated end to end against a real local wanna-build instance, not just the
dose binary in isolation: a test source with a foreign Build-Depends goes from
BD-Uninstallable to needs-build once the foreign Packages file is added,
unpatched binary stays at BD-Uninstallable as a regression check.
Architecture:all packages, your 2015 point: dose-builddebcheck satisfies a
Build-Depends from whichever Packages file has a qualifying version, so if the
native and the foreign file disagreed on an arch:all version, the native build
could be credited with the foreign one. Reproduced with a deliberately skewed
pair of files. Two things cover it. The trigger already generates every
per-architecture Packages file from the same archive sync in one loop, so they
agree by construction. And the foreign file is passed with its Architecture:
all stanzas stripped (grep-dctrl), so only the native file ever provides
arch:all packages. With that, the skewed case correctly stays BD-Uninstallable.
wanna-build itself still does not enforce this, kept as a TODO test.
Patch and tests are on a branch of a fork of wanna-build. Not requesting a
merge, Issues and MRs are disabled on this project. Posting here in case it
helps:
https://salsa.debian.org/mendezr/wanna-build/-/tree/foreign-arch-build-depends
Tests: a new tests/foreign-arch-bd.t on the existing WBTest harness covers
native-only, native plus one and two foreign files, the production file shape
(main plus build-essential plus foreign), identical arch:all duplicates, the
stripped foreign file, and the rejected inputs (mismatched --arch,
mixed-architecture file). Full suite passes, 118 tests.
This seems to just be AI output without a human actually making a point.
We have no intention to add foreign architectures to builds at this
point in time.
Kind regards
Philipp Kern
