Bug#1082212: Depends/Build-Depends cycle with libgtk-4-dev

[Simon McVittie]

Control: tags -1 + moreinfo

On Thu, 19 Sep 2024 at 20:43:15 +0900, Simon Richter wrote:
> when bootstrapping gtk 4, libsysprof-4-dev is one of the indirect build
> dependencies of gtk-4, but itself depends on libgtk-4-dev.

libsysprof-4-dev is obsolete and no longer exists in testing/unstable. It
was my understanding that new architectures are bootstrapped in unstable,
and we do not support adding new architectures to an existing stable
release, at least not without deploying a time machine that I don't have
access to? Is that wrong?

In the trixie cycle, packages that have sysprof capture integration
(instrumentation that feeds extra information into sysprof), like glib2.0
and gtk4, should only Build-Depend on libsysprof-capture-4-dev which is
a more minimal package without GLib or GTK dependencies.

Those packages should also limit their dependency on
libsysprof-capture-4-dev to architectures where sysprof already exists
(which means it is irrelevant when bootstrapping new architectures),
and ideally they should have a build profile to turn off the sysprof
integration if re-bootstrapping an existing architecture (for example
glib2.0 has pkg.glib2.0.nosysprof which can be used if a re-bootstrap
is required).

For gtk4 the cycle can also be broken from the sysprof end, by building
sysprof with the pkg.sysprof.nogui build profile (see below).

gtk4 does not currently have a pkg.gtk4.nosysprof build profile, but it
should be easy to add if you want to send a patch (debian/rules already
allows building without sysprof on architectures where it isn't buildable,
so it should be a simple matter of wiring up the build profile itself).

I don't think glib2.0 had its sysprof integration enabled in bookworm,
so it presumably didn't participate in any cyclic dependencies.

Helmut Grohne has been testing the re-bootstrapping case by using
GLib's pkg.glib2.0.nosysprof build-profile (and others), e.g. in
https://salsa.debian.org/gnome-team/glib/-/merge_requests/42, and reports
that it is successful when using glib2.0 from experimental.
glib2.0 in unstable has other re-bootstrapping issues unrelated to
sysprof, but fixing those in testing/unstable is currently blocked
by getting the new version of src:architecture-properties migrated
(#1081799), for which I'm waiting for
https://salsa.debian.org/debian/architecture-properties/-/merge_requests/6
to be merged and released.

> It would be nice if there was a way to bootstrap, e.g. splitting off the
> UI classes into a separate libsysprof-4-ui-dev and a build profile
> without these packages

This already exists in testing/unstable. The sysprof development files
have been split into libsysprof-capture-4-dev (minimal dependencies),
libsysprof-6-dev (requires GLib and friends), and the sysprof UI
(requires GTK).

In testing/unstable there is no longer a public shared library for the UI
parts of sysprof, and all of the UI stuff is now internal to sysprof.deb
(which can be turned off by building with -Ppkg.sysprof.nogui).

A pkg.sysprof.nogui build profile for src:sysprof already existed in
bookworm in a different form. I don't know whether that version was fully
effective, but if it wasn't, we can't retroactively fix it in the past.

    smcv