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

[Simon McVittie]

Control: severity -1 normal

On Thu, 25 Mar 2021 at 20:46:37 +0100, Andreas Beckmann wrote:
> On 25/03/2021 18.16, Simon McVittie wrote:
> > 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'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 .

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.

> > 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.
> 
> I'm leaving this bug for you to implement this or downgrade severity or
> close it.

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