Bug#1065316: libatspi2.0-dev 2.51.90-1 no longer multi-arch installable due to dependencies

Simon McVittie smcv at debian.org
Sun Mar 3 00:43:12 GMT 2024


Control: clone -1 -2
Control: reassign -2 gobject-introspection 1.78.1-15
Control: retitle -2 dh_girepository: generates unwanted dependency on libgirepository1.0-dev if that package is installed
Control: severity -2 important

On Sun, 03 Mar 2024 at 00:40:52 +0100, Samuel Thibault wrote:
> Christian Klein, le sam. 02 mars 2024 16:33:15 +0100, a ecrit:
> > libatspi2.0-dev is no longer muti-arch installable.
> > It now has a dependency on libgirepository1.0-dev, which isn't multi-arch.
> > 2.50.0-1 didn't have that dependency
> > 
> > Looking at the changelog, I don't see why the additional dependency is
> > necessary.
> 
> This is coming from gir:Depends:
> 
> ./debian/libatspi2.0-dev.substvars:gir:Depends=gir1.2-atspi-2.0 (= 2.51.90-1), gir1.2-dbus-1.0-dev, gir1.2-gobject-2.0-dev, libgirepository1.0-dev
> 
> I don't know the ins and outs why this comes like this, thus asking for
> help on this.

This was an unintended regression caused by changes made in
gobject-introspection, ironically to make multiarch co-installability and
cross-compilation of GObject-Introspection data possible. I am sorry to
have inconvenienced you and will try to fix the bug in dh_girepository
soon. I know that regressions are unacceptable, but this week there have
been several unrelated time-sensitive issues for which I have been made
a single point of failure, so I hope you will forgive me for not putting
this right at the top of my queue.

The bug is that if libgirepository1.0-dev is installed, dh_girepository
will wrongly generate dependencies on that package in preference to
gir1.2-glib-2.0-dev. This is because, for backwards compatibility
with packages that have not yet been updated to look for GIR XML
in a multiarch-friendly location, libgirepository1.0-dev provides a
symbolic link to the architecture-specific GIR XML for GLib-2.0 in a
non-multiarch-friendly location. This backwards compatibility glue is also
the reason why libgirepository1.0-dev cannot be Multi-Arch: same.

Samuel or other AT-SPI maintainers, if you want to avoid this unwanted
dependency while also bringing libatspi2.0-dev one step closer to being
cross-compilable itself, please consider replacing the build-dependency on
libgirepository1.0-dev with the canonicalized package names corresponding
to the GIR modules required by the upstream source, which according to
the build log means this:

diff --git a/debian/control b/debian/control
index 5408552..1dd2830 100644
--- a/debian/control
+++ b/debian/control
@@ -11,8 +11,10 @@ Build-Depends: dpkg-dev (>= 1.22.5), debhelper-compat (= 13),
                libx11-dev, libxtst-dev,
                meson (>= 0.63.0),
                pkgconf,
-               libgirepository1.0-dev,
                gtk-doc-tools, gi-docgen, python3-sphinx,
+               gir1.2-dbus-1.0-dev,
+               gir1.2-glib-2.0-dev,
+               gir1.2-gobject-2.0-dev,
                gobject-introspection | dh-sequence-gir,
                xauth <!nocheck>,
                xvfb <!nocheck>,

(Compile-tested only, I have not attempted to verify that the resulting
binaries are perfect; at the moment I'm only looking at this while I wait
for an urgent glib2.0 bug fix to finish running automated tests, and I
will have to re-prioritize back to glib2.0 as soon as it is ready. I
apologise for not providing an exhaustively-tested, production-ready
solution right now.)

    smcv



More information about the Pkg-a11y-devel mailing list