Bug#1060904: vapigen, valadoc: Please search the same paths for GIR XML that GObject-Introspection does
Simon McVittie
smcv at debian.org
Tue Jan 16 11:06:09 GMT 2024
Package: valac
Version: 0.56.14-1
Severity: important
Tags: trixie sid
User: pkg-gnome-maintainers at lists.alioth.debian.org
Usertags: gi-gir-path
Steps to reproduce
------------------
$ podman run --rm -it debian:sid-slim
# apt update
# apt install valac libportal-dev gir1.2-glib-2.0-dev
# apt remove libgirepository1.0-dev
# vapigen --library=libportal --pkg=gio-2.0 /usr/share/gir-1.0/Xdp-1.0.gir
Expected result
---------------
libportal.vapi is generated successfully
Actual result
-------------
error: Package `GLib-2.0' not found in specified Vala API directories or GObject-Introspection GIR directories
Workaround
----------
# apt install libgirepository1.0-dev
# vapigen --library=libportal --pkg=gio-2.0 /usr/share/gir-1.0/Xdp-1.0.gir
Generation succeeded - 0 warning(s)
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 vapigen and valadoc 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 vapigen and valadoc will become
unable to process it.
I think the best way to solve this in vapigen and valadoc would be to
propose changes upstream to make it use the same search path as
gobject-introspection, resolving upstream issue
https://gitlab.gnome.org/GNOME/vala/-/issues/1518,
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 to search the ${libdir}, like the
attached (which is untested - sorry, I don't really know Vala).
Implementing this will also be an enabler for being able to cross-compile
packages that contain Vala bindings. I will open a separate bug report
for that, since the best solution for that is not completely obvious.
smcv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Look-for-GIR-files-in-compile-time-libdir-datadir.patch
Type: text/x-diff
Size: 3287 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/attachments/20240116/939fca95/attachment.patch>
More information about the pkg-gnome-maintainers
mailing list