Bug#1060916: blueprint-compiler: Please search the same paths for GIR XML that GObject-Introspection does

[Simon McVittie]

Package: blueprint-compiler
Version: 0.10.0-4
Severity: wishlist
Tags: trixie sid upstream
User: pkg-gnome-maintainers at lists.alioth.debian.org
Usertags: gi-gir-path
Forwarded: https://gitlab.gnome.org/jwestman/blueprint-compiler/-/issues/142

The gobject-introspection package had a long-standing bug that
GLib-2.0.gir was installed in /usr/share, but has architecture-dependent
contents, preventing it from being co-installed on different
architectures. Recent versions solve this by moving GLib-2.0.gir
to /usr/lib/${DEB_HOST_MULTIARCH}/gir-1.0 (in the gir1.2-glib-2.0-dev
package), and configuring gobject-introspection to search that path.

Unfortunately, various other packages like blueprint-compiler also
want to read GIR XML, and they don't search the same directories
for it that gobject-introspection does. For backwards compatibility,
gobject-introspection still installs a symbolic link
/usr/share/gir-1.0/GLib-2.0.gir -> ../../lib/${DEB_HOST_MULTIARCH}/GLib-2.0.gir
in the libgirepository1.0-dev package to avoid breaking those tools,
but I would prefer that symlink to disappear eventually.

There is at least one other package that has an architecture-dependent
GIR XML file: GstAudio-1.0.gir in libgstreamer-plugins-base1.0-dev
(https://bugs.debian.org/1016631). Having a symbolic link in /usr/share
is probably not an option here, because there's no convenient package
split to take advantage of; but if we move GstAudio-1.0.gir into
/usr/lib/${DEB_HOST_MULTIARCH}, then blueprint-compiler will become
unable to process it.

I was unable to find a trivial test-case where this breaks
blueprint-compiler in practice, because it doesn't seem to resolve GIR XML
dependencies recursively, and I don't know of any GUI libraries that need
to have their GIR XML moved into /usr/lib/${DEB_HOST_MULTIARCH}; but I
know essentially nothing about this particular package, so if a maintainer
can find a scenario where it matters in practice, it might be necessary
to raise this bug's severity.

The ideal way to solve this would be to propose changes upstream to
make it use the same search path as gobject-introspection, resolving
<https://gitlab.gnome.org/jwestman/blueprint-compiler/-/issues/142>,
and then apply those changes in Debian (as a backported patch if
necessary) and configure it in a suitable way so that it searches
/usr/lib/${DEB_HOST_MULTIARCH}.

Thanks,
    smcv