Bug#1115340: transition: glib2.0 2.86

Package: release.debian.org
Severity: normal
Tags: moreinfo
X-Debbugs-Cc: [email protected], [email protected]
Control: affects -1 + src:glib2.0
User: [email protected]
Usertags: transition
Control: block -1 by 1115332

glib2.0 (>= 2.86) in experimental has a couple of issues that need 
resolving before it can be uploaded to unstable, so I'm opening this 
transition-tracking bug to coordinate what still needs to be done before 
we can have GLib 2.86 in unstable/testing. I don't think we're ready to 
go ahead with this yet, hence marked moreinfo. Unfortunately there is no 
straightforward fact about the affected packages that can be used to 
create a transition tracker.

The main issue is GObject-Introspection. The new GLib has not broken its 
C API/ABI, but it includes an introspection API break which affects 
language bindings:

* in bookworm, Unix-specific parts of libglib and libgio were part of
  the GLib-2.0.{gir,typelib} and Gio-2.0.{gir,typelib} introspection
  modules

* in trixie (specifically GLib 2.80 and up), the Unix-specific parts were
  duplicated into GLibUnix-2.0 and GioUnix-2.0; the idea was that the
  duplicates in GLib-2.0 and Gio-2.0 could be deprecated but remain for
  compatibility

* but the duplication, itself, turned out to cause problems for the
  GObject-Introspection machinery

* now, in 2.86, the Unix-specific parts have been removed from GLib-2.0
  and Gio-2.0, and language bindings need to adjust to that

Windows-specific parts have followed the same path, but obviously we 
never had those in Debian.

The route that upstream is mainly using to handle this is teaching 
language bindings to behave as if the OS-specific parts were still 
present in GLib-2.0 and Gio-2.0, but automatically look them up in 
GLibUnix-2.0 and GioUnix-2.0, with appropriate deprecation warnings - in 
practice it seems that the language bindings are better-placed to do 
this than GObject-Introspection itself.

Because GLibUnix-2.0 and GioUnix-2.0 already exist, many of the affected 
packages can be fixed immediately, even before we are ready to migrate 
glib2.0.

Packages known to be affected:

* awesome: fixed upstream, the change is not yet in Debian or Ubuntu
* cinnamon: fixed in 6.4.12-1, currently in unstable, should migrate in
  a few days; might need a rebuild (binNMU or no-changes sourceful upload)
  when the new GLib is available, I'm unsure on this particular point
* cjs: fixed in Ubuntu (128.0-1ubuntu1)
* gjs: fixed in experimental but that's probably for a later transition;
  in the meantime there are patches that could be backported (the same ones
  used in cjs 128.0-1ubuntu1)
* glib-d #1115332
* gnome-shell: fixed in experimental but that's a later transition;
  there are patches that could be backported, but it will also need a
  sourceful upload with a build-dependency on the new GLib if I
  understand correctly
* pygobject: fixed in 3.50.0-6, currently in unstable, should migrate soon

For the packages that are affected at runtime, glib2.0 has been gaining 
versioned Breaks to make sure they all migrate together.

We're probably at a point where it would be useful to report bugs in the 
remaining known-affected packages (perhaps excluding cinnamon and 
pygobject whose fixes will migrate soon anyway) and make them block this 
one.

Additionally there was an autopkgtest regression in lua-lgi, not 
directly unrelated to the GLibUnix/GioUnix thing, but this has been 
avoided by a change in glib2.0.

There might also be regressions seen in other dynamic bindings: 
libglib-object-introspection-perl, lua-lgi, and the ruby-gir-ffi family. 
These are only used for individual apps, therefore less critical than 
cjs/gjs/pygobject which are used for whole desktop environments.

And there might be regressions in apps that use static bindings (Rust, 
Haskell, Go, etc.) which would manifest as FTBFS - most likely as FTBFS 
in the leaf packages that use them, I think?

See also previous discussion on 
<https://salsa.debian.org/gnome-team/glib/-/merge_requests/56> and 
<https://salsa.debian.org/gnome-team/meta-gnome/-/issues/1>.

    smcv