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
