On 2021-09-25 11:49:39 +0100, Simon McVittie wrote:
> Control: retitle 995032 GNOME components segfault as a result of libffi 
> transition
> 
> On Sat, 25 Sep 2021 at 03:48:20 -0400, Jeremy Bicha wrote:
> > On Sat, Sep 25, 2021 at 12:30 AM Michael Ott <mich...@k-c13.org> wrote:
> > > The problem is not gnome-shell. It is the gobject-introspection.
> > > After downgrade this packages from 1.70.0-1+b1 to 1.70.0-1 it works
> > > again.
> > 
> > gobject-introspection was rebuilt as part of the libffi transition.
> > (That's where the +b1 part of the version name comes from.) The
> > transition is still in progress. Maybe the problem is that you didn't
> > have the rebuilt gjs installed?
> > 
> > The rebuilt gjs is version 1.68.4-1+b1
> > 
> > Here's the list of other packages involved in the transition:
> > https://release.debian.org/transitions/html/auto-libffi.html
> 
> Last time we had a libffi transition, in early 2020, we ended up
> sprinkling versioned Breaks throughout GNOME to force the whole system
> to be either "old libffi" or "new libffi". This is because some GNOME
> components, notably gobject-introspection, have libffi data structures
> in their public API, so in partial upgrades we get one library passing an
> old-libffi data structure to another library that expects a new-libffi
> data structure, and crashes.
> 
> See the gobject-introspection 1.62.0-4 and -5 changelogs for part of what
> we had to do to fix this.
> 
> If libffi is going to continue to break ABI somewhat regularly, then I
> think we are going to need a more systematic way to prevent broken partial
> upgrades, and it would be very helpful for the libffi maintainer and the
> release team to keep this failure mode in mind when allocating transition
> slots (for example doing libffi transitions when there is not a new major
> version of GLib trying to migrate, as there is at the moment).

Regardless of future transitions of libffi, if glib and the
introspection ecosystems are closely tied to the the libffi ABI, the
affected packages need to express that with the proper dependencies. We
have the same situation with boost and icu and boost and python3.X.

If you implement a similar solution to that in boost, this would also
allows us to track this via ben in a future libffi transition.

Cheers
-- 
Sebastian Ramacher

Attachment: signature.asc
Description: PGP signature

Reply via email to