On 2021-09-25 14:55:23 +0100, Simon McVittie wrote:
> On Sat, 25 Sep 2021 at 15:01:46 +0200, Sebastian Ramacher wrote:
> > 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.
> 
> It's not that they are closely tied to any specific libffi ABI - to the
> best of my knowledge, they're all fine with any reasonable version of
> libffi, old or new. The problem is that gobject-introspection and all
> users of girffi.h[1] (gjs, pygobject, etc.) all need to be using the
> *same* libffi, because girffi.h has functions that return pointers to ffi
> types or take pointers to ffi types as parameters.

Sorry, that's not what I meant. they are tightly coupled in the sense
that the whole gobject-introspection ecosystem needs to use the same
libffi version. It's the same as boost and icu where also icu's ABI
leaks into boost's ABI (via some icu structs that are passed around).
Hence everything that uses Boost.Regex needs also be tracked in icu
transitions. To track that, libboost-regexX provides
libboost-regexX-icuY and reverse dependencies have dependencies on
libboost-regexX-icuY.

For libgirepository1.0-1 that would mean that
libgirepository1.0-1 provides libgirepository1.0-1-ffiX and symbols from
girffi that depend on the specific libffi ABI then declare in the
symbols files that dependencies on libgirepository1.0-1-ffiX need to be
generated.

Cheers

> 
> I don't know whether it is important that glib2.0 and gobject-introspection
> are *also* using the same libffi; in the past we assumed that they should,
> but it is probably not critical.
> 
> [1] https://codesearch.debian.net/search?q=girffi.h&literal=1
> 
>     smcv

-- 
Sebastian Ramacher

Attachment: signature.asc
Description: PGP signature

Reply via email to