Re: Bug#1016631: libgstreamer-plugins-base1.0-dev: please return to Multi-Arch: same by moving GIR XML to ${libdir}
Control: retitle -1 libgstreamer-plugins-base1.0-dev: please return to Multi-Arch: same by moving GstAudio-1.0.gir to ${libdir}/gir-1.0
On Wed, 15 Feb 2023 at 12:50:05 +0000, Simon McVittie wrote:
> The reason why GstAudio-1.0.gir is not multi-arch co-installable is that
> it includes constants like GST_AUDIO_FORMAT_S16 which is defined to be
> an alias for either GST_AUDIO_FORMAT_S16LE or GST_AUDIO_FORMAT_S16BE,
> whichever is the native endianness. It is not possible for g-ir-scanner
> to produce identical GIR XML for this module on little-endian and
> big-endian machines, because the correct contents are genuinely different,
> and GIR XML does not have any mechanism for architecture conditionals.
The GObject-Introspection package in Debian now has a suitable search
path entry for architecture-dependent GIR XML, which is ${libdir}/gir-1.0
(or equivalently /usr/lib/${DEB_HOST_MULTIARCH}/gir-1.0).
Most GIR XML can stay in /usr/share, it's only a minority of libraries
(like this one) that need to change the installation directory. This is
similar to the way we install 95% of C/C++ header files into /usr/include,
but for the minority of C/C++ headers that are architectecture-dependent,
we also have /usr/include/${DEB_HOST_MULTIARCH} available.
So, the maintainers of libgstreamer-plugins-base1.0-dev could now make it
Multi-Arch: same again, by moving the one GIR XML file that is
architecture-dependent to that directory. This is probably easiest to
achieve by editing debian/libgstreamer-plugins-base1.0-dev.install and
replacing
usr/share/gir-*/GstAudio-1.0.gir
with
usr/share/gir-1.0/GstAudio-1.0.gir usr/lib/${DEB_HOST_MULTIARCH}/gir-1.0
(I haven't tested this, but it should work). The cost of this is that it
will probably break the bindings generators listed by this UDD query:
https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=pkg-gnome-maintainers%40lists.alioth.debian.org&tag=gi-gir-path
At the time of writing that's cppgir (fixed upstream), haskell-haskell-gi,
gir-to-d and possibly blueprint-compiler. I don't know whether any of these
are used to generate bindings from /usr/share/gir-1.0/GstAudio-1.0.gir
during their Debian package builds in practice.
Until those tools' upstream code can be fixed, packages that use
those tools could probably mitigate this at build time by locating
GstAudio-1.0.gir in debian/rules, copying it into a temporary build
directory, and running their code-generation step with that temporary
build directory added to the XDG_DATA_DIRS.
If GStreamer is relevant to cross-compilation, please consider making this
change before the trixie freeze. If you are concerned about the possible
impact on generated bindings, making this change in experimental so that
they have a proposed version to test against would be a good first step.
Thanks,
smcv
Reply to: