On Sat, 28 Jun 2025 at 12:04:27 -0400, Jeremy Bícha wrote:
On Sat, Jun 28, 2025 at 11:30 AM Sebastian Ramacher <sramacher@debian.org> wrote:On 2025-06-28 09:05:13 -0400, Jeremy Bícha wrote: > For forky, we intend to move architecture-dependent gstreamer .gir > files to /usr/lib/${DEB_HOST_MULTIARCH}/gir-1.0 and set Multi-Arch: > same. Why is this not done now?Simon is concerned that some gobject-introspection language bindings generators have not yet been updated to handle gir files that are installed to architecture-dependent directories.
An analogy might be helpful: it's as though gcc had been updated to search both /usr/include/TUPLE and /usr/include, but all of our other C/C++ toolchains were still only searching /usr/include, which would make it a regression risk for us to move C/C++ headers to /usr/include/TUPLE at this stage.
most generators have been updated for [this change]
I think that's perhaps misleading. The only components that have been updated to search /usr/lib/TUPLE/gir-1.0 are the ones that are part of src:glib2.0 and src:gobject-introspection, primarily g-ir-compiler and gi-compile-repository, which compile GIR XML into architecture-dependent binary typelibs to be used by dynamic languages like Python and JavaScript.
This is enough for typical C/C++ libraries, but doesn't help third-party bindings generators (and in particular, based on https://codesearch.debian.net/search?q=Gst-1.0&literal=1&perpkg=1 I think moving Gst-1.0.gir might break src:gtk-d and one of the examples in src:cppgir).
Specifically, these are the affected generators we know about: https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-gnome-maintainers%40lists.alioth.debian.org&tag=gi-gir-path
... and notice that there are no closed bugs on that list, only open bugs. (cppgir was briefly fixed, but the update to a new upstream git snapshot was reverted, re-introducing the bug.)
smcv