Bug#985890: libglib2.0-0: usage of glib_check_version() should generate tight package dependencies

[Simon McVittie]

On Thu, 25 Mar 2021 at 15:05:21 +0100, Andreas Beckmann wrote:
> during buster -> bullseye upgrade tests with piuparts I observed some
> failures related to glib dependencies:
> 
>   Setting up libclutter-imcontext-0.1-bin (0.1.4-3.1) ...
>   Cannot load module /usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im-ibus.so: GModule (/usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im-ibus.so) initialization check failed: GLib version too old (micro mismatch)

This seems more like a bug in ibus-clutter to me? I would expect most
calls to glib_check_version() to be more like this:

    if (glib_check_version (2, 64, 0) == NULL)
      do something the new way
    else
      do something the old way

like these arbitrarily-chosen examples from codesearch:

https://sources.debian.org/src/gmime/3.2.7-1/gmime/gmime-charset.c/?hl=196#L196
https://sources.debian.org/src/pidgin-skype/20140930+svn665+dfsg-1/libskype.c/?hl=417#L417
https://sources.debian.org/src/gst-plugins-good1.0/1.18.3-1/gst/udp/gstudp.c/?hl=35#L35

If ibus-clutter wants to second-guess the dependency system and do a
runtime check, it should probably be checking against the (hard-coded)
version it requires, not the version it happens to have been compiled
against; or it seems less problematic to do a check that ignores the
micro version, like fcitx5-gtk does:
https://sources.debian.org/src/fcitx5-gtk/5.0.3-1/gtk2/fcitxim.c/?hl=24#L24

We do set the Build-Depends-Package in the symbols file, so making
ibus-clutter build-depend on its required GLib version should do the
right thing without needing any runtime checks.

> Using the glib_check_version() symbol should generate package
> dependencies that ensure the version check passes.

I think this would give us unnecessarily strict dependencies that result
in trouble with getting packages migrated - I'd prefer to avoid having
more packages stuck behind GLib than we strictly have to, and it would
seem slightly absurd for gst-plugins-good to get a dependency on GLib
2.66.8 as a result of wanting to print a warning if run against GLib
2.35 or older...

There's also a cost to this for the glib2.0 source package: we'd have
to either generate the symbols file at build-time from a template, or
remember to update the symbols file by hand when importing new upstream
releases (which is fine if there's a good reason, but not OK if it's
neutral or counterproductive).

Perhaps it would be more reasonable to special-case this function
in the symbols file to generate a dependency on at least version
${major}.${minor}.0? That would accommodate what fcitx5-gtk does, and
seems like a better boundary for stable (x.even.z) releases at least.

    smcv