Package: cppgir
Version: 2.0-2
Severity: normal
Tags: trixie sid
User: [email protected]
Usertags: gi-gir-path
Steps to reproduce
------------------
$ podman run --rm -it debian:sid-slim
# apt update
# apt install cppgir libportal-dev gir1.2-glib-2.0-dev
# apt remove libgirepository1.0-dev
# cppgir --output /tmp/gir /usr/share/gir-1.0/Xdp-1.0.gir
(libportal-dev is a relatively small GLib-based library and Xdp-1.0.gir
is its corresponding GIR XML - you could use any GLib-dependent library
for this)
Expected result
---------------
Bindings are generated successfully
Actual result
-------------
ERROR could not find GIR for GLib-2.0
Workaround
----------
# apt install libgirepository1.0-dev
# cppgir --output /tmp/gir /usr/share/gir-1.0/Xdp-1.0.gir
(success)
Or use the --gir-path option, or the $GI_GIR environment variable.
Discussion
----------
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 programs like cppgir 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 cppgir will become unable to
process it.
I think the best way to solve this in cppgir would be to propose changes
upstream to make it use the same search path as gobject-introspection,
resolving upstream issue https://gitlab.com/mnauw/cppgir/-/issues/66,
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}.
If that cannot be done in the near future, a less good alternative would
be to have a Debian-specific patch hard-coding it to search
/usr/lib/${DEB_HOST_MULTIARCH}.
Thanks,
smcv