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