Bug#1078929: glib2.0 breaks architecture bootstrap

[Simon McVittie]

Control: tags -1 + patch moreinfo

On Wed, 04 Sep 2024 at 11:30:14 +0100, Simon McVittie wrote:
> libglib2.0-dev: metapackage with complete GLib development files
>    |- M-A: same (install for host)
>    |
>    |- Depends: libgio-2.0-dev: development files for GLib, GObject, GIO
>    |   |- M-A: same (install for host)
>    |   |- Provides: libglib-2.0-dev
>    |   |- Provides: libgobject-2.0-dev
>    |   |- optionally Provides: libgmodule-2.0-dev for completeness
>    |   |- optionally Provides: libgthread-2.0-dev for completeness
>    |   |
>    |   \- Depends: libgio-2.0-dev-bin: development utilities for GLib, GObject, GIO
>    |       |- M-A: foreign (install for build)
>    |       |- Breaks/Replaces: libglib2.0-dev-bin (<< this)
>    |       \- Depends: python3, python3-packaging (needed by gdbus-codegen)
>    |
>    \- Depends: girepository-tools
>        |- M-A: same (install for host)
>        |- Breaks/Replaces: libglib2.0-dev (<< this)

I've pushed a possible concrete implementation of this to:
https://salsa.debian.org/gnome-team/glib/-/merge_requests/42
(autopkgtests and piuparts pass, otherwise untested).

Helmut, does this split do what you need?

I decided to make libglib2.0-dev depend directly on libgio-2.0-dev-bin
instead of having libgio-2.0-dev depend on it, so that very simple uses
of GLib (linking to its libraries but not using glib-mkenums or similar
CLI development tools) don't need to pull in the CLI tools and therefore
don't always need to depend on Python, which might improve flexibility
for how bootstrap/cross problems are solved.

I didn't include a build-profile to turn off generation of
girepository-tools, because I assumed that it would be OK to generate
uninstallable packages during the cross phase of bootstrapping, as long
as nothing that is built during that phase needs to depend on them.
That should be easy to add if it's needed, though.

I would expect use of these split packages in bootstrapping to go
something like this:

1. build glib2.0 for the cross-building architecture if necessary
   (for libgio-2.0-dev-bin and Architecture: all)
2. cross-build glib2.0 on the cross-building architecture for the desired
   architecture, with -B -Pnogir
3. modify other packages that are needed during the cross phase, such as
   libverto, to build-depend on libgio-2.0-dev and possibly
   libgio-2.0-dev-bin instead of libglib2.0-dev
4. after the cross phase is finished, rebuild glib2.0 natively without nogir

Or, if qemu-user can emulate the desired architecture, then step 2 can
use that to build a complete glib2.0 package and step 4 can be skipped.

> girepository-tools-bin

It turns out we don't actually need this package, because everything that
it would have contained needs to be a host-architecture executable
(possibly wrapped by cross-exe-wrapper) rather than a wrapped
build-architecture executable.

    smcv