Bug#985610: unblock: glib2.0/2.66.8-1 (+ advice on #985890)

[Simon McVittie <smcv@debian.org>]

Control: reopen -1
Control: retitle -1 unblock: glib2.0/2.66.8-1 (+ advice on #985890)

On Sat, 20 Mar 2021 at 17:08:14 +0000, Simon McVittie wrote:
> * Sync up with upstream 2.66.8 release, 95% of which we already apply
>   via debian/patches
> * Add an error-handling patch from upstream that they recommended I
>   consider including when backporting recent security fixes to buster
> * Add missing CVE ID references to changelog

It looks as though some packages, like ibus-clutter (#985453),
second-guess the dependency mechanism by applying their own check
that GLib is at least the (micro!) version they were compiled
against. Pseudocode:

    if ((message = glib_check_version (GLIB_MAJOR_VERSION,
                                       GLIB_MINOR_VERSION,
                                       GLIB_MICRO_VERSION)) != NULL) {
        fatal_error (message);
    }

where glib_check_version() acts on the runtime GLib version, and
GLIB_MAJOR_VERSION etc. are the compile-time GLib version. I personally
think that's a harmful pattern, especially if the micro version is
included in the check, but I can understand upstreams that have it not
wanting to remove it.

For now, would it be possible to apply some age-days to glib2.0 to make
it migrate sooner than 14 days' time? That would mitigate this.

For a long-term solution, #985890 (currently RC but I'll probably
downgrade it) suggests that we should special-case glib_check_version()
in the .symbols file to generate a dependency on the upstream version
of GLib that was present at compile-time. I'm somewhat reluctant to do
that, because that will make it harder to get GLib-dependent packages
migrated if they are using the *other* common pattern for use of
glib_check_version():

    if (glib_check_version (2, 35, 3) == NULL) {
        work around a bug in GLib < 2.35.3, or do something the old way
    }
    else {
        do something the new way
    }

How would the release team prefer to handle this in future? I think the
options go like this:

1. Don't treat glib_check_version() specially in the .symbols file: it's
   just another symbol, marked as having been introduced in GLib 2.6.
   If packages second-guess the dependency system, either we should patch
   that out, or those packages are responsible for generating a more strict
   GLib dependency for themselves.

2. Special-case glib_check_version() to generate a dependency on
   libglib2.0-0 (>= MAJOR.MINOR.0). If packages second-guess the dependency
   system, make sure they are only checking for MAJOR.MINOR.0, on the basis
   that GLib stable branches (MAJOR.MINOR.z, MINOR%2 == 0) do not introduce
   new ABI. Packages that use it to check against a hard-coded version
   will be slightly harder to migrate than they are now (when we upgrade
   to a new minor version of GLib, which we do once per 6 months,
   they'll get stuck behind it).

3. Special-case glib_check_version() to generate a dependency on
   libglib2.0-0 (>= MAJOR.MINOR.MICRO) as requested by #985890. Packages
   that use it to check against a hard-coded version will be harder
   to migrate (when we upgrade to a new micro version of GLib, which I
   estimate we do once per 2-8 weeks, they'll get stuck behind it).

Thanks,
    smcv