Bug#1115340: transition: glib2.0 2.86
Package: release.debian.org
Severity: normal
Tags: moreinfo
X-Debbugs-Cc: glib2.0@packages.debian.org, debian-gtk-gnome@lists.debian.org
Control: affects -1 + src:glib2.0
User: release.debian.org@packages.debian.org
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
Reply to: