Hi,

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)
  /usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im-ibus.so does not export Clutter IM module API: GModule (/usr/lib/x86_64-linux-gnu/clutter-imcontext/immodules/im-ibus.so) initialization check failed: GLib version too old (micro mismatch)
  dpkg: error processing package libclutter-imcontext-0.1-bin (--configure):
   installed libclutter-imcontext-0.1-bin package post-installation script subprocess returned error exit status 1

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


Andreas

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.
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

I've posted a patch to the ibus-clutter bug that tightens the dependency
to (>= upstream_version). The should be the minimal solution for
bullseye, it should be revisited for bookworm .

I'm leaving this bug for you to implement this or downgrade severity or
close it.


Andreas

Control: severity -1 normal

Thanks for doing that! I agree that this design seems a good solution
for bullseye but should probably be fixed in a nicer way for bookworm.
I haven't reviewed the implementation, so no positive or negative opinion
on that.

I'm inclined to go with what the release team say, because they're
our domain experts on balancing the risk of regressions during partial
upgrades against making transitions feasible. I gave them some options
on #985610 (either leaving it as-is, this compromise, or generating a
tight dependency like you initially proposed), and Sebastian Ramacher
preferred the idea of leaving it as-is.

For now I'm just downgrading this bug, but if other release team members
don't object to what Sebastian said, then I'll close this as "not a bug,
working as intended" without further action.

Thanks,
    smcv

Release team conclusion seems to be that this was an ibus-clutter bug,
and there is nothing to be done about it in GLib; closing the GLib side
as not-a-bug.

    smcv