Bug#1071246: libglib2.0-dev's python3 dependency alternative is posing challenges to cross building

[Helmut Grohne <helmut@subdivi.de>]

Package: libglib2.0-dev
Version: 2.80.2-1
User: debian-cross@lists.debian.org
Usertags: ftcbfs
Control: affects -1 + src:tkgate
X-Debbugs-Cc: debian-cross@lists.debian.org

Hi Simon,

you recently added an alternative python3 to the qemu dependency. This
is posing a challenge to cross building now, but the devil is in the
detail.

On a technical level, python3 | qemu expresses what we want. The crossqa
service sees this and has special handling for python3. It considers
python3.*-minimal to not be installable for the host architecture (as
that pratically fails postinst). We're checking dependencies with dose
and dose is quite clever in coming up with creative solutions. It has no
problems figuring out that qemu is the solution here. Hence, reverse
dependencies (tkgate being an example here) are scheduled for building
and then apt looks at the dependencies. It sees python3 as the first
alternative and is generally happy with installing the host one. Hence,
it doesn't look beyond and doesn't consider qemu. The python3:any
dependency show up later and the host's python3 happens to satisfy it.
Hence apt is happy until python3-minimal:host.postinst fails.

Arguably, this is a problem of the builder. Package depedencies cannot
tell whether we can install a foreign python or not. That's a question
only the builder can answer and David added a fiddle to apt quite a
while ago that is called "BarbarianArchitectures" and documented as a
list of architectures considered too foreign to satisfy M-A:foreign.
Even though python3 isn't actually M-A:foreign, adding this setting
immediately makes the build work and you can try that by adding this to
your sbuild invocation:

    --chroot-setup-commands='echo "APT::BarbarianArchitectures {\"arm64\"};" > /etc/apt/apt.conf.d/b.conf'

I also tried reordering the python3 dependencies in libglib2.0-dev such
that the python3:any comes first, but that did not have any effect.

Do we see another way than changing the way that sbuild (and pbuilder)
performs cross builds?

I note that this bug has a bit of urgency, because affected packages
will be marked as bd-uninstallable and that is taken as a sign to stop
trying to build the relevant architecture and makes crossqa.d.n stop
doing builds until the next mirror push. So this bug breaks QA.

Helmut