Bug#1078929: glib2.0 breaks architecture bootstrap

[Helmut Grohne]

Source: glib2.0
Version: 2.81.1-3
Severity: important
User: helmutg at debian.org
Usertags: rebootstrap
X-Debbugs-Cc: debian-cross at lists.debian.org

Hi Simon,

I fear we need to have another conversation about glib2.0 and
bootstrapping. At the time you refactored it, architecture bootstrap was
largely broken by gcc and linux disagreeing and I am now getting back to
fixing it, but the changes in glib2.0 leave me in despair.

For one thing, it now pulls qemu when cross building, but we cannot have
qemu in architecture cross bootstrap as qemu often isn't ready when we
need to bootstrap. That's a deal breaker.

Then, I figured that I definitely need to build with the new build
profiles nogir and pkg.glib2.0.nosysprof. Going without either causes a
direct loop. Thanks for adding them. But even then, cross build fails
really quickly:

debian/rules:30: *** Cross-compiling gobject-introspection requires host endianness = build endianness.  Stop.

That's another deal breaker.

So we need to go back to the drawing board and figure out how we want to
bootstrap glib2.0 for new architectures as what we did earlier no longer
works. The first and most significant choice here is whether it should
be part of the native phase or the cross phase. We used have an implied
answer to this. We require that all essential packages are build during
the cross phase. base-passwd happens to be essential and it happens to
need cdebconf. While cdebconf has a lot of build profiles, none of them
turn of its dependency on libglib2.0-dev. Hence glib2.0 was part of the
cross phase. Being part of the cross phase means that it actually must
be cross buildable without qemu for big endian architectures and that's
what no longer works.

We may attempt to push glib2.0 out of the cross phase. Possibly cdebconf
can be made to build without glib2.0. I see that glibc, libidn2,
libprelude, libverto and libxt have glib in their native dependency
tree. They're all part of the cross phase. At least libverto and libxt
directly depend on the host's libglib2.0-dev with no profile. We can try
this, but it's not going to be easy.

Let's assume that we succeed at getting glib2.0 out of the cross phase
and we magically arrive at a build-essential package set for our new
architecture. Now we want to natively build glib2.0. I see that you took
care of the obvious and building glib2.0 with all possible profiles
enabled does not cause libglib2.0-0t64 to be installed. That's great.
Thank you.  Let's look into Build-Depends and Build-Depends-Arch.

dbus-daemon <!nocheck> <!noinsttest>, gettext, libdbus-1-dev <!nocheck> <!noinsttest>, libsysprof-capture-4-dev (>= 3.38.0) [amd64 arm64 armel armhf i386 mips64el ppc64el riscv64 s390x powerpc ppc64] <!pkg.glib2.0.nosysprof>, python3-docutils <!nodoc>, desktop-file-utils <!nocheck>, dh-sequence-gir <!nogir>, gobject-introspection (>= 1.78.1-18~) <!nogir>, locales <!nocheck> | locales-all <!nocheck>, python3-dbus <!nocheck>, python3-gi <!nocheck>, qemu-user <cross !nogir>, shared-mime-info <!nocheck>, tzdata <!nocheck>, xterm <!nocheck>
 -> ok, turn on profiles
debhelper-compat (= 13), pkgconf,
 -> ok, practically build-essential
dh-sequence-gnome,
 -> ok, Arch:all, no non-trivial dependencies
dh-sequence-python3,
 -> maybe ok, Arch:all, we must build python3 before glib2.0, might work
docbook-xml, docbook-xsl,
 -> probably ok, Arch:all, the docbook stack seems mostly Arch:all
dpkg-dev (>= 1.22.5), linux-libc-dev [linux-any],
 -> ok, build-essential
libelf-dev, libffi-dev, libmount-dev [linux-any], libpcre2-dev, libselinux1-dev [linux-any], zlib1g-dev
 -> ok, we already have to build these in the cross phase before glib2.0
libxml2-utils,
 -> ok, libxml2 has simple Build-Depends
meson (>= 1.2.0),
 -> non-trivial, Arch:all, but it pulls ninja-build and a few Python
    dependencies. I suspect a loop here.
python3-packaging:native,
 -> probably ok, Arch:all, trivial dependencies
python3:native,
 -> maybe ok, we must build python3 before glib2.0, might work
xsltproc,
 -> maybe, non-trivial dependency tree, nothing really outstanding,
    might work

I think there are two sticking issues here. One is Python. Cross
building Python used to work in the cross phase, but that was before
removing glib2.0. I expect that we also have to remove Python. The other
is meson. It pulls e.g. cmake via ninja-build. This definitely does not
just work.

Do you see any way of splitting libglib2.0-0t64 and libglib2.0-dev into
more granular packages with the goal of being able to cross build
something smaller for another endianess? In order to be useful, it would
have to be split in such a way that we can actually reduce a build
dependency of relevant packages to the smaller thing.

Do you see any other options (short of giving up being able to bootstrap
Debian) that I missed here?

I'll do some work on removing dependencies on libglib2.0-dev, but my
expectation is that this will not save us and only make us better
understand the dependency loops involved.

Helmut