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.
