Bug#1064369: gobject-introspection dropped versioned dependency on python3
Simon McVittie
smcv at debian.org
Tue Feb 20 21:50:33 GMT 2024
Control: tags -1 + moreinfo
On Tue, 20 Feb 2024 at 22:15:21 +0100, Matthias Klose wrote:
> The package had in the past dependencies of the form
>
> python3 (<< 3.12), python3 (>= 3.11~), python3:any
>
> the new one just
>
> python3:any
>
> This leads to badly triggered autopkg tests, with a mismatching
> python3-defaults. Afaik, gobject-introspection can only handle the default
> python version, not all supported python versions.
The parts that require a specific python3 version are now in the
gobject-introspection-bin binary package, which correctly depends on:
python3 (<< 3.12), python3 (>= 3.11~), python3:any
via dh_python and ${python3:Depends}. The gobject-introspection package
no longer contains any binary Python extensions. This was necessary to be
able to make it a Multi-Arch: same wrapper around a build-architecture
gobject-introspection-bin.
As far as I can see, it would not be straightforward to add a
lockstep-Python-version dependency to gobject-introspection, because it
does not directly contain any binary Python extensions itself (although
of course anyone wanting to prove me wrong is welcome to provide an
implementation).
gobject-introspection depends on gobject-introspection-linux-little-endian
(= 1.78.1-15) (or -big-endian on s390x, etc.). That's a virtual package
provided by gobject-introspection-bin, ensuring that gobject-introspection
and gobject-introspection-bin are upgraded in lockstep; so it should
not be possible to install a mismatched set.
What is the situation that is going wrong in autopkgtest? Can you perhaps
provide a log?
If gobject-introspection explicitly depended on gobject-introspection-bin
by name (not just via a virtual package), would that help?
Thanks,
smcv
More information about the pkg-gnome-maintainers
mailing list