Bug#905715: Directory for .gir (gobject-introspection) files? (Multi-Arch)
Helmut Grohne
helmut at subdivi.de
Wed Feb 20 16:03:43 GMT 2019
Hi Simon,
On Sat, Feb 16, 2019 at 05:02:53PM +0000, Simon McVittie wrote:
> 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.
This is not specific to Debian. It is an upstream problem. The files are
supposed to be architecture-independent, but factually are not.
> 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).
Exactly. And indeed, Martin pointed to Peter Pearse's earlier effort.
Unfortunately, this has stalled since. The takeaway here is: We're not
going to fix this in Debian only and it will take a long while.
> 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.
And this is where we should consider whether working on this problem is
worth the effort. Deriving from the binary practically happens by
loading it into some tool. I don't remember the details here, but this
where things break down: The purpose of these GIR files is software
development. Why would you install them for multiple architectures?
Only if you are cross compiling something. But then you load libraries
into some tool, you're faced with an Exec format error. This doesn't
work at all regardless of whether fix the M-A annotations.
For this reason, I think that
> Another is to remove the M-A: same annotation.
is the way to go. Anything that has gobject-introspection anywhere in
its Build-Depends (directly or indirectly), effectively is not cross
buildable on Debian. See
https://bootstrap.debian.net/cross_all/gobject-introspection.html.
Working on these GIR files is doing the second step before the first (or
maybe in parallel). However, it's certainly not something that we'll fix
in time for buster.
In a similar vein, valac currently is practically broken for cross
compilation in Debian. If you need to do cross compilation on Debian,
avoid gnome-ish stuff. Qt/kde-ish stuff tends to work a lot better. I'm
not opposed to making it work, but it isn't a small fix to a few
packages.
You may ask: How do other distributions solve this? Well, ptxdist and
yocto use qemu for gobject-introspection.
Helmut
More information about the pkg-gnome-maintainers
mailing list