Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1188614 > unrolled thread

Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition Simon McVittie <smcv@debian.org> - 2024-03-01 13:00 +0100
    Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition Christoph Berg <myon@debian.org> - 2024-03-01 13:30 +0100
    Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition Helmut Grohne <helmut@subdivi.de> - 2024-03-01 16:10 +0100
      Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition Sam Hartman <hartmans@debian.org> - 2024-03-01 16:50 +0100
      Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition Stefano Rivera <stefanor@debian.org> - 2024-03-01 17:20 +0100
        Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition Simon McVittie <smcv@debian.org> - 2024-03-01 18:50 +0100
          Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition Simon McVittie <smcv@debian.org> - 2024-03-02 21:30 +0100
            Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition Simon McVittie <smcv@debian.org> - 2024-03-02 23:10 +0100
            Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition Simon McVittie <smcv@debian.org> - 2024-03-03 03:10 +0100
            Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition Simon McVittie <smcv@debian.org> - 2024-03-06 13:10 +0100
    Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition Matthew Garrett <mjg59@srcf.ucam.org> - 2024-03-04 01:00 +0100
      Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition Sam Hartman <hartmans@debian.org> - 2024-03-04 17:00 +0100
        Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition Simon McVittie <smcv@debian.org> - 2024-03-04 17:20 +0100
          Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition Matthew Garrett <mjg59@srcf.ucam.org> - 2024-03-04 17:50 +0100

#1188614 — Bug#1065170: tech-ctte: Requesting advice on glib2.0 #1065022, file deletion by postrm during t64 transition

Package: tech-ctte
Severity: normal
X-Debbugs-Cc: debian-dpkg@lists.debian.org, debian-gtk-gnome@lists.debian.org, vorlon@debian.org

I'm requesting advice from the tech-ctte (or anyone else with relevant
knowledge, e.g. the dpkg team or the drivers of the time64 transition)
on how to resolve glib2.0 bug #1065022. This is time-sensitive,
because it is a RC bug (temporarily breaking many applications across
this transition) and will hold up the time64 transition.

Background
==========

glib2.0 has two similar patterns where files that are managed by dpkg
are summarized in a non-dpkg-managed file, maintained by triggers and the
library postinst/postrm.

The first of these patterns is GSettings schemas. There is a tool that
loads GSettings schemas in XML format from /usr/share/glib-2.0/schemas
and aggregates them into a single binary blob in a more efficient format,
/usr/share/glib-2.0/schemas/gschemas.compiled. For performance reasons,
applications only load gschemas.compiled: there is no support for loading
the more authorable but less efficient XML files directly.

The second of these patterns is GIO modules, a plugin architecture which
loads .so files from /usr/lib/${DEB_HOST_MULTIARCH}/gio/modules
and summarizes their functionality
in /usr/lib/${DEB_HOST_MULTIARCH}/gio/modules/giomodule.cache.
Applications that want to load plugins parse giomodule.cache, and only
dlopen the plugins that provide the desired functionality (for example
an application that doesn't do any networking will not load plugins that
only implement gio-proxy-resolver).

This is implemented with dpkg file-based triggers: when a package adds
or removes GSettings schemas or GIO modules, it triggers processing by
the libglib2.0-0{,t64} postinst. The implementation has been approximately
the same shape for 10 years, and has worked well until now.

Because dpkg doesn't have an equivalent of RPM %ghost files, the two
generated summary files need to be deleted by the library's postrm.
As of bookworm (and still true in trixie), the implementation is:

- for giomodule.cache (per-architecture), the file is simply deleted by
  postrm remove

- for gschemas.compiled (shared by all architectures), if the multiarch
  refcount of the library reaches 0, then the file is deleted during the
  next postrm purge

The bug
=======

When we transition from libglib2.0-0 to libglib2.0-0t64, this involves
the removal of libglib2.0-0. In the postrm of libglib2.0-0, removing
libglib2.0-0:amd64 deletes
/usr/lib/x86_64-linux-gnu/gio/modules/giomodule.cache, and so on for
all the other architectures.

The result is that until the postinst of libglib2.0-0t64:amd64 is run,
amd64 applications will be unable to load GIO plugins, causing
functionality loss (for example, inability to use https, because the
TLS plugin is not loaded).

Similarly, either during or after the transition from libglib2.0-0
to libglib2.0-0t64, users will want to purge libglib2.0-0. In
the postrm of libglib2.0-0, if there are no multiarch
instances of libglib2.0-0 remaining, purging the package deletes
/usr/share/glib-2.0/schemas/gschemas.compiled. The result is that
applications that want to load GSettings schemas will not find their
required schemas, which is normally treated as a programming error
(incorrect installation) that causes a crash with an assertion failure.

The workaround is: after removal or purging of libglib2.0-0, reinstall
either libglib2.0-0t64 or any package that will trigger libglib2.0-0t64.
On multiarch systems, this must be done for the architecture that matches
the instance of libglib2.0-0 that was removed.

During upgrade, I am unsure what ordering guarantees we have about
the postrm of libglib2.0-0 running before or after the postinst of
libglib2.0-0t64 - perhaps we avoid the giomodule.cache bug in practice,
because the postrm runs before the postinst? But purge can happen at any
later time, so we certainly cannot guarantee that libglib2.0-0t64.postinst
will run after purging libglib2.0-0.

I apologise for not having foreseen this.

Non-solutions
=============

I am not interested in solutions that would require a use of a time
machine to change the postrm that was shipped in bookworm: bookworm was
already released, and now we are stuck with it. *After* the time-sensitive
part of this issue has been solved, I plan to look into making the postrm
robust against future transitions similar to this one by adding some way
for the new package to take over responsibility for giomodule.cache and
gschemas.compiled, but for this particular transition it's too late: the
first time at which we could rely on that functionality is trixie -> forky.

I am also not interested in solutions that require design changes in GLib,
for example adding a fallback slow-path that ignores the absence of the
summary files and loads the individual GSettings schemas and GIO modules
directly. This is because upstream would not accept such a change, and it
would introduce significant delta into Debian, which we would potentially
never be able to remove (because the removed libglib2.0-0 can be purged
at any later date). I consider the deletion of these summary files to
be a packaging problem, which we should be able to solve in packaging.

Possible solution: delete libglib2.0-0.postrm in libglib2.0-0t64.preinst
========================================================================

libglib2.0-0t64 could gain a preinst that deletes
/var/lib/dpkg/info/libglib2.0-0:${DEB_HOST_ARCH}.postrm. This is a clear
Policy violation, but perhaps between closely cooperating packages
(glib2.0 and, er, glib2.0) it would be the least-bad answer to this?

There is nothing else in the postrm other than the two problematic file
deletions (I'll have to check bookworm, but this is certainly true for
trixie) so I think there would not be any harmful side-effect of this,
other than the Policy violation.

Possible solution: revert t64 rename for glib2.0
================================================

According to Ubuntu's ABI analysis, glib2.0 only has a small number of
symbols that refer to time_t:

- g_bookmark_file_get_added
- g_bookmark_file_get_app_info
- g_bookmark_file_get_modified
- g_bookmark_file_get_visited
- g_bookmark_file_set_added
- g_bookmark_file_set_app_info
- g_bookmark_file_set_modified
- g_bookmark_file_set_visited
- g_date_set_time_t

This seems like maybe a manageable amount to handle with versioned Breaks?

g_date_set_time_t() is the only one that is not already deprecated, and
according to codesearch.debian.net, the only one that is widely used.
Its use of time_t is as an input parameter (not via a pointer), so callers
will certainly all use the correct ABI after a simple rebuild (binNMU).

The GBookMarkFile stuff is primarily used by the GtkBookmarkManager
in gtk+2.0 and gtk+3.0, plus ardour (which has a reimplementation of
GtkBookmarkManager for whatever reason) and a bunch of language bindings.

So perhaps we could transition back from libglib2.0-0t64 to libglib2.0-0,
and give it a versioned Breaks on older versions of the dependent
packages, NMU'ing the dependent packages if necessary to ensure that
we know a version number that is guaranteed to be on the "new" side of
the line?

After the time-critical part of this transition has happened, one of
the things on my extensive to-do list is looking into whether we can
change these functions upstream to give them inline wrappers, so that all
newly-compiled C/C++ code will call the wrapper and not the underlying
symbol (for example an inline version of g_bookmark_file_get_added()
would be implemented in terms of g_bookmark_file_get_added_date_time(),
which returns a non-time_t-sensitive object). However, this certainly
won't happen upstream until the GLib 2.82 cycle, which will be too late
for Ubuntu 24.04; and my to-do list is very long, so I would strongly
prefer the Debian project not to be blocking on me, personally, having
time to do this.

Possible solution: other ideas?
===============================

Perhaps someone in the technical committee or another relevant team has
a better plan?

I would like advice on how the GNOME team should proceed: one of the
possible solutions I've outlined, or some different thing.

If the solution that is chosen is a Policy violation (like deleting
the problematic postrm) then I would also like to have clarity that the
Policy violation is tolerable as a less-bad solution, and therefore will
not itself be treated as a RC bug in trixie.

If the solution that is chosen involves mass NMUs with only trivial
changes (to force the existence of a version number that is on the time64
side of the transition, so we can use it in Breaks), then I would like
permission for the GNOME team to carry out those NMUs on a 0-day basis.

Thanks,
    smcv

[toc] | [next] | [standalone]

#1188626

Re: Simon McVittie
> libglib2.0-0t64 could gain a preinst that deletes
> /var/lib/dpkg/info/libglib2.0-0:${DEB_HOST_ARCH}.postrm. This is a clear
> Policy violation, but perhaps between closely cooperating packages
> (glib2.0 and, er, glib2.0) it would be the least-bad answer to this?

That doesn't sound too bad to me.

> Possible solution: other ideas?

Make glib2.0-t64 use a different cache filename?

> If the solution that is chosen is a Policy violation (like deleting
> the problematic postrm) then I would also like to have clarity that the
> Policy violation is tolerable as a less-bad solution, and therefore will
> not itself be treated as a RC bug in trixie.

I would tend to treat policy as a set of rules that you normally
shouldn't break, but if there's a clear argument why it makes sense in
given case, it would be quite silly to reject that solution just
because of formal reasons.

Christoph

[toc] | [prev] | [next] | [standalone]

#1188651

Hi Simon,

On Fri, Mar 01, 2024 at 11:50:22AM +0000, Simon McVittie wrote:
> Background
> ==========

Thank you for explaining the details so clearly.

> - for giomodule.cache (per-architecture), the file is simply deleted by
>   postrm remove

For this one (but not gschemas.compiled), I am wondering whether
installing a trigger-interest in /usr/share/doc/libglib2.0-0/copyright
might work. That is a file that is going away and therefore, removal of
libglib2.0-0 should cause libglib2.0-0t64.postinst to be invoked with a
triggered argument after libglib2.0-0.postrm having done the damage.

Do you agree that this would solve giomodule.cache but not
gschemas.compiled?

Of course, not solving the other one makes this somewhat theoretical.
Your answer still helps me verify that I correctly understood the
problem.

> - for gschemas.compiled (shared by all architectures), if the multiarch
>   refcount of the library reaches 0, then the file is deleted during the
>   next postrm purge

Do you happen to remember why gschemas.compiled is being removed in
purge rather than remove? Again an answer to this question does not help
you mitigate the symptoms.

> Possible solution: delete libglib2.0-0.postrm in libglib2.0-0t64.preinst
> ========================================================================
> 
> libglib2.0-0t64 could gain a preinst that deletes
> /var/lib/dpkg/info/libglib2.0-0:${DEB_HOST_ARCH}.postrm. This is a clear
> Policy violation, but perhaps between closely cooperating packages
> (glib2.0 and, er, glib2.0) it would be the least-bad answer to this?

Consider a variant of this. We don't really know how old libglib2.0-0
is and I'm not sure anyone of us wants to look into multiple old
libglib2.0-0.postrm scripts. Your removal assumes that it never did
anything important. A lesser assumption would be that it always has been
a shell script. We could insert an invocation of

    dpkg-trigger --no-await libglib2.0-0-removal

and have libglib2.0-0t64 declare the matching trigger interest.

Both of my thoughts leave a window of time where users of these caches
will fail. Removing the postrm instead will close this window.

I locally verified that removing a postrm will not make dpkg --verify
unhappy.

> Possible solution: revert t64 rename for glib2.0
> ================================================
> 
> According to Ubuntu's ABI analysis, glib2.0 only has a small number of
> symbols that refer to time_t:
> 
> - g_bookmark_file_get_added
> - g_bookmark_file_get_app_info
> - g_bookmark_file_get_modified
> - g_bookmark_file_get_visited
> - g_bookmark_file_set_added
> - g_bookmark_file_set_app_info
> - g_bookmark_file_set_modified
> - g_bookmark_file_set_visited
> - g_date_set_time_t
> 
> This seems like maybe a manageable amount to handle with versioned Breaks?
> 
> g_date_set_time_t() is the only one that is not already deprecated, and
> according to codesearch.debian.net, the only one that is widely used.
> Its use of time_t is as an input parameter (not via a pointer), so callers
> will certainly all use the correct ABI after a simple rebuild (binNMU).
> 
> The GBookMarkFile stuff is primarily used by the GtkBookmarkManager
> in gtk+2.0 and gtk+3.0, plus ardour (which has a reimplementation of
> GtkBookmarkManager for whatever reason) and a bunch of language bindings.
> 
> So perhaps we could transition back from libglib2.0-0t64 to libglib2.0-0,
> and give it a versioned Breaks on older versions of the dependent
> packages, NMU'ing the dependent packages if necessary to ensure that
> we know a version number that is guaranteed to be on the "new" side of
> the line?
> 
> After the time-critical part of this transition has happened, one of
> the things on my extensive to-do list is looking into whether we can
> change these functions upstream to give them inline wrappers, so that all
> newly-compiled C/C++ code will call the wrapper and not the underlying
> symbol (for example an inline version of g_bookmark_file_get_added()
> would be implemented in terms of g_bookmark_file_get_added_date_time(),
> which returns a non-time_t-sensitive object). However, this certainly
> won't happen upstream until the GLib 2.82 cycle, which will be too late
> for Ubuntu 24.04; and my to-do list is very long, so I would strongly
> prefer the Debian project not to be blocking on me, personally, having
> time to do this.

Do you see this as a realistic solution for trixie?

> Possible solution: other ideas?
> ===============================
> 
> Perhaps someone in the technical committee or another relevant team has
> a better plan?

While removing the postrm is a policy violation, we also understand its
effects quite well. If we have a choice between having all of unstable
(and later trixie) users crash their user sessions and violate policy,
the pragmatic voice in me wants to say yes.

I understand that the answer is time critical now as most unstable users
(like myself) will run into this problem rather soon. Would you mind if
an answer for unstable differs from an answer for (released) trixie? If
that other approach gets implemented, we can still revert the transition
(before trixie is released) and thus avoid this policy violation to show
up in an actual Debian release.

Helmut

[toc] | [prev] | [next] | [standalone]

#1188655

Are there solutions in the space of having glib2.0-0 continue to exist
as a package depended on by glib2.0-0t64 or depending on the new library
allowing you to replace the postrm?
That might create a space in time where glib2.0-0.so does not exist, but
we probably have more flexibility there than  we do with essential
packages.

[toc] | [prev] | [next] | [standalone]

#1188659

Hi Helmut (2024.03.01_14:58:10_+0000)
> For this one (but not gschemas.compiled), I am wondering whether
> installing a trigger-interest in /usr/share/doc/libglib2.0-0/copyright
> might work. That is a file that is going away and therefore, removal of
> libglib2.0-0 should cause libglib2.0-0t64.postinst to be invoked with a
> triggered argument after libglib2.0-0.postrm having done the damage.

One concern I have here: It's possible to configure dpkg to skip
installing /usr/share/doc/* with --path-exclude. I don't know what
effect that has on such triggers, but I assume they wouldn't be
triggered.

> While removing the postrm is a policy violation, we also understand its
> effects quite well. If we have a choice between having all of unstable
> (and later trixie) users crash their user sessions and violate policy,
> the pragmatic voice in me wants to say yes.

Yeah, agreed on that.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/
  +1 415 683 3272

[toc] | [prev] | [next] | [standalone]

#1188666

On Fri, 01 Mar 2024 at 13:21:51 +0100, Christoph Berg wrote:
> > Possible solution: other ideas?
> 
> Make glib2.0-t64 use a different cache filename?

I'm not happy about the idea of introducing long-term divergence in
the upstream code as a result of a Debian-specific packaging problem;
I think we should be going in the direction of fewer, not more,
"weird Debianisms" that break reasonable upstream assumptions.

If there was a finite time window after which we could revert this, that
would be less bad, but as far as I can see it would be possible to keep
libglib2.0-0 installed for multiple release cycles and then purge it, and
it would have just as much impact whenever it happens to get purged.

On Fri, 01 Mar 2024 at 15:58:10 +0100, Helmut Grohne wrote:
> For this one (but not gschemas.compiled), I am wondering whether
> installing a trigger-interest in /usr/share/doc/libglib2.0-0/copyright
> might work. That is a file that is going away and therefore, removal of
> libglib2.0-0 should cause libglib2.0-0t64.postinst to be invoked with a
> triggered argument after libglib2.0-0.postrm having done the damage.
> 
> Do you agree that this would solve giomodule.cache but not
> gschemas.compiled?

Probably? Sorry, I don't have a sufficiently in-depth understanding of
the finer points of triggers to know whether it is guaranteed that the
trigger would go off after libglib2.0-0.postrm has already run.

(Also, as said elsewhere, sysadmins are allowed to remove/exclude
/usr/share/doc, so I wouldn't want to make that load-bearing.)

> Of course, not solving the other one makes this somewhat theoretical.

Right; the schemas problem is the more serious one anyway. So I don't
think it's necessarily worth spending time on bringing my understanding
of triggers up to a point where I would be able to answer your previous
question.

> > - for gschemas.compiled (shared by all architectures), if the multiarch
> >   refcount of the library reaches 0, then the file is deleted during the
> >   next postrm purge
> 
> Do you happen to remember why gschemas.compiled is being removed in
> purge rather than remove?

I don't remember, as such (it was before my involvement) but thankfully
we have version control to answer questions like this for us. According
to the git history, it was originally removed in remove, but that caused
breakage during upgrades (which run the old postrm and then, eventually,
the new postinst): there was a window of time in which the file did
not exist.

For GIO modules, having a window of breakage is not great but not a
disaster, because "most" GLib programs are at least partially functional
without them. Perhaps giomodules.cache should *also* only be removed
during purge, but fixing that has never been anyone's highest priority.

For GSettings schemas, missing schemas are usually treated as a
programming error (assertion failure and hard crash) which caused more
extensive brokenness:

    debian/libglib2.0-0.postrm.in: Only remove the compiled schemas on purge,
    not during upgrades. Otherwise we have no schemas available until the new
    postinst is run, which leads to applications aborting on missing schemas.
    — c8b28bc30b4a5ca7ec7bf643ebaeae88bf21c588, 2012-03-30

> > libglib2.0-0t64 could gain a preinst that deletes
> > /var/lib/dpkg/info/libglib2.0-0:${DEB_HOST_ARCH}.postrm
> 
> Consider a variant of this. We don't really know how old libglib2.0-0
> is

The postrm was introduced in 2010 and hasn't changed a whole lot (14
commits between the beginning of time and current experimental, according
to git log -p --follow debian/libglib2.0-0t64.postrm in the experimental
packaging).

> and I'm not sure anyone of us wants to look into multiple old
> libglib2.0-0.postrm scripts

We don't support skipping an upgrade, so probably only the one in bookworm
(and Ubuntu 22.04 I suppose) is relevant here?

If my choice is between spending O(hours) on reading old postrm scripts
or O(days) on NMUing GLib-dependent packages, then I'd prefer to read
the postrm scripts. I can't say that either is something I would look
forward to, but if it's what the project requires from me then it will
have to happen.

> Both of my thoughts leave a window of time where users of these caches
> will fail.

Yes, and in the case of GSettings schemas that does seem particularly
high-impact.

> > Possible solution: revert t64 rename for glib2.0
> 
> Do you see this as a realistic solution for trixie?

Which is "this"?

If you mean reverting the rename and adding Breaks, then yes, it's a
simple matter of doing an extensive amount of of routine work (rename
back, no-changes-NMU all packages that mention those symbols if necessary
so that they will have a higher version number, and add versioned Breaks).
I can't say that I'm looking forward to that work, particularly if the
project expects me to do all of it personally, but it's routine.
I don't know how it would fit into Ubuntu's schedules and deadlines, but
if the alternative is "most GLib applications crash" then they would
presumably prefer the route that doesn't have those crashes.

If you mean adding inline shims to the upstream headers so that the
affected symbols never actually get called, then I think it's feasible
for trixie but absolutely not feasible for Ubuntu 24.04, and I cannot
guarantee that it can happen at all (upstream might reject it, or I
might get preempted by other work for the rest of the trixie cycle).

> I understand that the answer is time critical now as most unstable users
> (like myself) will run into this problem rather soon. Would you mind if
> an answer for unstable differs from an answer for (released) trixie?

That's fine, as long as we're aware that anything that needs to happen
before Ubuntu 24.04's import freeze can either happen before that point
or not at all, with no third option.

I'm sorry that coordination with Ubuntu is imposing deadlines on us for
this, but I didn't have the opportunity to choose the timing or design
of the time64 transition, and I'm just trying to resolve brokenness as
fast as I can within my limited capabilities.

> If that other approach gets implemented, we can still revert the transition
> (before trixie is released) and thus avoid this policy violation to show
> up in an actual Debian release.

In principle yes, although if we have long-term divergence between
Debian and Ubuntu around the name of a package as low down the stack as
libglib2.0-0, then that's probably also not good. If we go that route then
we would probably want one of libglib2.0-0 and libglib2.0-0t64 to be a
transitional package depending on the other one.

On Fri, 01 Mar 2024 at 08:44:24 -0700, Sam Hartman wrote:
> Are there solutions in the space of having glib2.0-0 continue to exist
> as a package depended on by glib2.0-0t64 or depending on the new library
> allowing you to replace the postrm?

If libglib2.0-0 continues to exist, then packages that expect the affected
entry points to have 32-bit time_t will still have their dependencies
satisfied, but then when they call the affected entry points, they will
crash, because their time_t is not the same size as GLib's. So as far
as I can see, this is functionally equivalent to reverting the rename:
to be correct, it would have to be accompanied by versioned Breaks on
every package that calls into the affected entry points.

    smcv

[toc] | [prev] | [next] | [standalone]

#1188840

I have proposed a change for glib2.0/experimental at
https://salsa.debian.org/gnome-team/glib/-/merge_requests/32 which
implements the "delete the old postrm" approach. I would appreciate
review and comments on whether this is something that would be acceptable
to upload to experimental, and/or to cherry-pick to the debian/trixie
branch that is currently being used for unstable uploads.

I believe it is ready for review, and it includes semi-automated
tests for #1065022, which do pass for a test-build; but at the time of
writing I am waiting for the systematic testing that is appropriate for
a production-quality upload, because it takes a long time (around 1 to
2 hours of sbuild, autopkgtest and piuparts in the case of glib2.0). I
hope that I am not wasting reviewers' time by asking for review of
only-partially-tested changes.

As well as the "delete the old postrm" part, the proposed change also
includes an attempt to prevent this situation from happening again, by
changing the postrm logic so the cleanup is not done if a future package
like libglib2.0-0xyz takes over /usr/lib/*/glib-2.0.

Because my upload pipeline is time-consuming and I only get a finite
number of attempts in a day, I would prefer it if reviewers could make
it clear whether any deficiencies are considered to be experimental
upload blockers, unstable upload blockers, or merely nice-to-have. If
only nice-to-have changes are requested, then I will not necessarily
restart the release process for them.

If I do not receive any positive or negative feedback by the time the
build finishes, I will probably upload it to DELAYED in an attempt to take
myself off the critical path, and I might also prepare a DELAYED upload
for unstable. This is an attempt to balance the two competing factors
that result in there being no acceptable thing to do in this situation:
because this is a critical bug that will eventually become critical-path
for a project-wide transition, the expectation is that I must upload a
fix as soon as possible, but because maintainer scripts run as root on
hundreds of thousands of systems, the expectation is that I must not
upload without sufficient testing. So, my intention is to do my best,
and then invite other developers to take responsibility for a better,
higher-version-numbered upload with different timing if they prefer.

On Fri, 01 Mar 2024 at 17:44:57 +0000, Simon McVittie wrote:
> Perhaps giomodules.cache should *also* only be removed
> during purge, but fixing that has never been anyone's highest priority.

That is also implemented in
https://salsa.debian.org/gnome-team/glib/-/merge_requests/32.

> On Fri, 01 Mar 2024 at 15:58:10 +0100, Helmut Grohne wrote:
> > I'm not sure anyone of us wants to look into multiple old
> > libglib2.0-0.postrm scripts
> 
> If my choice is between spending O(hours) on reading old postrm scripts
> or O(days) on NMUing GLib-dependent packages, then I'd prefer to read
> the postrm scripts. I can't say that either is something I would look
> forward to, but if it's what the project requires from me then it will
> have to happen.

I am currently downloading all versions of libglib2.0-0 that have
existed on amd64 as tracked by snapshot.d.o. My plan is to extract their
DEBIAN/postrm, import them into a git branch and go back through the
history that way. I am doing this in parallel with building a release
candidate for experimental rather than doing this analysis first, because
as stated above my release pipeline is very long, and I am optimistically
assuming that the code added by debhelper when it replaces the #DEBHELPER#
token will not be functionally significant. If that assumption is wrong
then I will presumably need to to start again and rethink my approach.

    smcv

[toc] | [prev] | [next] | [standalone]

#1188851

On Sat, 02 Mar 2024 at 20:19:50 +0000, Simon McVittie wrote:
> I am currently downloading all versions of libglib2.0-0 that have
> existed on amd64 as tracked by snapshot.d.o. My plan is to extract their
> DEBIAN/postrm, import them into a git branch and go back through the
> history that way.

https://salsa.debian.org/smcv/glib2.0-control-files has the full history.
`git log -p postrm` confirms that the only things the postrm has ever
done in versions known to snapshot.d.o are:

- deleting gschemas.compiled, which is what we want to avoid here;
- deleting giomodule.cache, which is what we want to avoid here;
- running ldconfig, which is handled by triggers now

So I think removing the postrm is viable.

    smcv

[toc] | [prev] | [next] | [standalone]

#1188860

On Sat, 02 Mar 2024 at 20:19:47 +0000, Simon McVittie wrote:
> I have proposed a change for glib2.0/experimental at
> https://salsa.debian.org/gnome-team/glib/-/merge_requests/32 which
> implements the "delete the old postrm" approach.

I've uploaded this to experimental, incorporating feedback from Helmut.
(Thank you for your thorough review!)

Due to the time required to put each version through build/testing,
I am not able to propose a corresponding upload for unstable tonight
(and having this version in experimental for at least a few hours is
probably not a bad plan in any case).

    smcv

[toc] | [prev] | [next] | [standalone]

#1189244

On Sat, 02 Mar 2024 at 20:19:47 +0000, Simon McVittie wrote:
> I have proposed a change for glib2.0/experimental at
> https://salsa.debian.org/gnome-team/glib/-/merge_requests/32 which
> implements the "delete the old postrm" approach

An equivalent glib2.0 change is now in unstable.

Unfortunately, GTK 2 and 3 both have an equivalent issue for their input
method modules (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065493,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1065494 respectively).
I'm proposing to address this in the same way as for glib2.0 with
https://salsa.debian.org/gnome-team/gtk2/-/merge_requests/3 and
https://salsa.debian.org/gnome-team/gtk3/-/merge_requests/22 respectively
(untested, test-builds are in progress). As with glib2.0, I apologise for
not having caught this at nmudiff time.

gdk-pixbuf and GTK 4 probably have a latent version of the same issue,
but have avoided a practical problem during this particular transition by
not having any time_t in their ABIs and therefore not needing a rename,
so they are presumably not immediately urgent to address.

I have not attempted to audit other libraries that have plugins, either
inside or outside the GNOME team, for an equivalent problem.

    smcv

[toc] | [prev] | [next] | [standalone]

#1188973

I agree with the conclusions drawn here, but feel that it's possibly 
worth making a stronger general statement that policy should never 
prevent the implementation of a well-considered simple solution. I would 
like some further analysis of Sam's proposal, though - I don't think 
there's any advantage in undoing the existing solution, but if it would 
work then it's maybe a more straightforward solution for any similar 
issues in future?

[toc] | [prev] | [next] | [standalone]

#1189049

>>>>> "Matthew" == Matthew Garrett <mjg59@srcf.ucam.org> writes:

    Matthew> I agree with the conclusions drawn here, but feel that it's
    Matthew> possibly worth making a stronger general statement that
    Matthew> policy should never prevent the implementation of a
    Matthew> well-considered simple solution. I would like some further
    Matthew> analysis of Sam's proposal, though - I don't think there's
    Matthew> any advantage in undoing the existing solution, but if it
    Matthew> would work then it's maybe a more straightforward solution
    Matthew> for any similar issues in future?

Unfortunately, I think Simon's response to me is definitive.
Ultimately if the old package exists, it will continue to satisfy
dependencies.
That's exactly what we don't want in the time_t transition.

I think we might revisit this when we come to a discussion of how our
tools could provide us more flexibility to make issues like usrmerge and
time_t transition easier in the future.

[toc] | [prev] | [next] | [standalone]

#1189053

Copying context from elsewhere in the thread, Sam Hartman wrote:
> Are there solutions in the space of having glib2.0-0 continue to exist
> as a package depended on by glib2.0-0t64 or depending on the new library
> allowing you to replace the postrm?

to which I replied:

If libglib2.0-0 continues to exist, then packages that expect the affected
entry points to have 32-bit time_t will still have their dependencies
satisfied, but then when they call the affected entry points, they will
crash, because their time_t is not the same size as GLib's. So as far
as I can see, this is functionally equivalent to reverting the rename:
to be correct, it would have to be accompanied by versioned Breaks on
every package that calls into the affected entry points.

On Mon, 04 Mar 2024 at 08:46:52 -0700, Sam Hartman wrote:
> >>>>> "Matthew" == Matthew Garrett <mjg59@srcf.ucam.org> writes:
>     Matthew> I would like some further
>     Matthew> analysis of Sam's proposal, though - I don't think there's
>     Matthew> any advantage in undoing the existing solution, but if it
>     Matthew> would work then it's maybe a more straightforward solution
>     Matthew> for any similar issues in future?
> 
> Unfortunately, I think Simon's response to me is definitive.
> Ultimately if the old package exists, it will continue to satisfy
> dependencies.
> That's exactly what we don't want in the time_t transition.

I think the one thing we could do in this direction would be to mitigate
problems like this one *on architectures unaffected by the transition*
(in this case, 64-bit plus i386) by having this situation:

Package: libglib2.0-0
Architecture: amd64 arm64 i386 s390x (etc.)
Depends: libglib2.0-0t64 (>= ${binary:Version})
Description: empty transitional package

Package: libglib2.0-0t64
Architecture: any
Breaks: libglib2.0-0 (<< ${binary:Version})
Replaces: libglib2.0-0 (<< ${binary:Version})
Description: GLib library

I think this would have made upgrades significantly more smooth on the
non-armel, non-armhf architectures, as well - but perhaps I'm missing an
important reason why the 64-bit time_t transition team have chosen not to
do this (and perhaps it's not even possible).

Nothing we do in this direction would help armel and armhf, so there would
still be a problem here to be solved (and probably we would not have found
out about this particular bug until much, much later, when an armel or
armhf GUI user did the upgrade and encountered the bug).

This is obviously only going to help if "most" architectures are
unaffected by the transition. If our next such transition involves
genuinely breaking ABI on the more widely-used architectures, then I
don't see any way to make it less painful. Perhaps this is a sign that
we should try hard to only have transitions shaped like this one if
there is no alternative.

    smcv

[toc] | [prev] | [next] | [standalone]

#1189055

On Mon, Mar 04, 2024 at 04:08:37PM +0000, Simon McVittie wrote:
> Copying context from elsewhere in the thread, Sam Hartman wrote:
> > Are there solutions in the space of having glib2.0-0 continue to exist
> > as a package depended on by glib2.0-0t64 or depending on the new library
> > allowing you to replace the postrm?
> 
> to which I replied:
> 
> If libglib2.0-0 continues to exist, then packages that expect the affected
> entry points to have 32-bit time_t will still have their dependencies
> satisfied, but then when they call the affected entry points, they will
> crash, because their time_t is not the same size as GLib's. So as far
> as I can see, this is functionally equivalent to reverting the rename:
> to be correct, it would have to be accompanied by versioned Breaks on
> every package that calls into the affected entry points.

Sorry, yes, because we're transitioning the package name but not the 
soname. My mistake.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web