On Tue, 22 Oct 2024 at 11:33:17 +0100, Simon McVittie wrote:
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.
Similarly, Gst-1.0.gir in libgstreamer1.0-dev is not multi-arch co-installable because GstIdStr contains a different amount of padding on different word sizes.
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 [the $libdir]
This wouldn't be practically useful until the same change has been carried out in libgstreamer1.0-dev. I'm preparing MRs for both packages.
With a preliminary version of the changes that I'm going to propose, I can successfully build libportal (which Build-Depends on libgstreamer-plugins-base1.0-dev) for both amd64 and i386 on the same system, without needing to use a chroot or container. (I did build profiles to turn off its Qt features, but those are orthogonal to its use of GStreamer.)
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
As far as I can tell from codesearch, there are no bindings in Debian that would actually be broken by these changes. There are Rust bindings for GstAudio and Gst, but they don't currently regenerate the Rust code from GIR XML at build-time; and there is a D binding for Gst (only), but similarly it doesn't currently regenerate the D code from GIR XML at build-time.
smcv