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