Bug#905715: Directory for .gir (gobject-introspection) files? (Multi-Arch)

[Simon McVittie]

(Cross-posting to debian-devel, but with Reply-To to the bug)

On Sat, 16 Feb 2019 at 09:32:16 +0100, W. Martin Borgert wrote:
> at the moment, .gir files are placed under /usr/share/gir-1.0/.
> However, such files can contain architecture specific content.
> What would be the right directory? /usr/share/gir-1.0/<triple>/?

The vast majority of GIR files are architecture-independent, so the
majority of GIR files should stay where they are in any case.

Multiarch-qualified directories under /usr/share don't seem like they make
much sense: the whole point of the $libdir/$datadir duality is that if
files need to be different on some architectures, then the files should
be in $libdir, not in $datadir.

However, the search path for GIR files is effectively part of the API
of gobject-introspection, and it's documented to use $XDG_DATA_DIRS as
defined in the freedesktop.org Base Directory specification (defaulting to
/usr/local/share:/usr/share as per the spec), so any change to how this
works would need to be discussed with gobject-introspection's upstream
developers (regardless of what the specific directory was).

My understanding is that GIR is intended to be a collection of
machine-readable facts about the source code, rather than facts about
the binary, which is why it's in /usr/share in the first place (unlike
the typelib, which is architecture-dependent). However, those facts are
partially derived from inspecting the binary, so can in principle end
up different in rare cases, and presumably that is what's happened here.

The program that generates GIR (g-ir-scanner) is architecture-independent
Python code, so it's easy to say "gobject-introspection should look in
its own $libdir/gir-1.0 in addition to $XDG_DATA_DIRS/gir-1.0", but
probably harder to actually implement than you might think.

One option for fixing this for buster, if it is considered to be urgent,
is to investigate what the difference is and whether it can be eliminated,
perhaps by wrapping the code that differs between architectures in
#ifndef __GI_SCANNER__.

Another is to remove the M-A: same annotation.

    smcv