Bug#1110825: libgirepository-2.0-0: ABI is dependent on current version of libffi

[Simon McVittie]

Package: libgirepository-2.0-0
Version: 2.84.4-1
Severity: important

libgirepository-2.0-0 has libffi data structures in its public API, 
specifically everything in <girepository/girffi.h>:

- gi_type_tag_get_ffi_type()
- gi_type_info_get_ffi_type()
- gi_type_info_extract_ffi_return_value()
- gi_type_tag_extract_ffi_return_value()
- gi_function_info_prep_invoker()
- gi_function_invoker_new_for_address()
- gi_function_invoker_clear()
- gi_callable_info_create_closure()
- gi_callable_info_get_closure_native_address()
- gi_callable_info_destroy_closure()

Next time libffi does an ABI transition, the ABI of these functions will 
change, but upstream is very unlikely to bump the SONAME of 
libgirepository-2.0-0 for this (because nothing under their control will 
have changed).

A mitigation is that as of trixie, nobody is using libgirepository-2.0-0 
yet: the only rdep in the archive is python3-gi/experimental. I expect 
that python3-gi and libgjs will both want to move to 
libgirepository-2.0-0 in the forky cycle, though.

The way we dealt with this for libgirepository-1.0-1 was to provide a 
virtual package with a mechanically-generated name:

    Package: libgirepository-1.0-1
    Version: 1.84.0-1
    Provides: libgirepository-1.0-1-with-libffi8 (= 1.84.0-1)

and make it generate dependencies on that virtual package:

    Package: python3-gi
    Depends: ..., libgirepository-1.0-1-with-libffi8 (>= 1.62.0-4~), ...

I think we should teach src:glib2.0 to do the same thing.

We might want to limit the dependency generation so that only the 
libffi-related functions listed above will generate a dependency on the 
virtual package, which would allow packages to call functions like 
gi_repository_prepend_library_path() without becoming dependent on a 
specific libffi.

    smcv