Control: forwarded -1 https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/323
On Sun, 29 Jan 2023 at 16:48:47 +0100, Helmut Grohne wrote: > There is basically three ways to fix this. One option is to change the > location of .gir files to /usr/lib/<triplet>/gir-1.0. I have tried to make this possible in the past[1], and upstream's response was quite negative[2], so this is not going to be straightforward. I'm sorry that I haven't had the necessary bandwidth to deal with everything that the project would like me to be responsible for, and I'm sorry that I don't have the necessary force of personality to compel upstream developers to treat our priorities as their priorities. The majority of GIR XML files *are* architecture-independent: it is usually only the lower-level ones, like GLib itself, that are not. I think anything in this direction needs to search both locations, so that upstream build systems that install into $XDG_DATA_DIRS do not cause regressions. In particular, upstream want the lookup to be based on $XDG_DATA_DIRS to make ad-hoc installation-from-source frameworks like jhbuild feasible to implement, and I really don't want to get into a situation like the one with Python dist-packages where incompatibilities between Debian and upstream result in everyone involved resenting us. To minimize regressions, I think we probably want "most" GIR XML files to remain in /usr/share, with only the ones that genuinely vary between architectures moved into an architecture-specific place. That would make their handling similar to C/C++ headers, which similarly are mostly placed in an architecture-independent location (/usr/include) but can be relocated into an architecture-specific location (/usr/include/TUPLE) when necessary. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=905715 https://gitlab.gnome.org/GNOME/gobject-introspection/-/issues/323 https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/258 [2] https://gitlab.gnome.org/GNOME/gobject-introspection/-/merge_requests/258#note_1250726 > The other option is to make gir files truly architecture-independent and > removing any architecture-specific aspects from them. This is not possible: the architecture-specific parts of at least GLib-2.0.gir are API, and might be required by consumers. There are two major categories of consumers of GObject-Introspection information: - interpreted language bindings like gjs and pygobject, which mostly consume the API via the architecture-dependent binary typelib files which are generated from the GIR XML, and for which the architecture-specific parts are probably useless; - compiled languages like Vala and Rust, which mostly consume the API via a code-generator that reads the GIR XML directly, and for which the architecture-specific parts are potentially important smcv
