Bug#1029957: g-ir-scanner: produces FHS violations by putting architecture-dependent files in /usr/share

[Simon McVittie]

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