On 2021-03-28 13:47:46 +0100, Simon McVittie wrote:
> 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.
Done.
>
> 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.
I prefer this option. If reverse dependencies misuse glib_check_version
without defining the proper dependencies, then they need to be fixed.
Cheers
>
> 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
>
--
Sebastian Ramacher
signature.asc
Description: PGP signature
