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
