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 <[email protected]>
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
