Bug#1064369: gobject-introspection dropped versioned dependency on python3

[Matthias Klose]

On 20.02.24 22:50, Simon McVittie wrote:
> 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?

see
https://autopkgtest.ubuntu.com/packages/m/meson/noble/ppc64el

the one triggered by python3-defaults/3.12.1-0ubuntu1 
gobject-introspection/1.79.1-1

> If gobject-introspection explicitly depended on gobject-introspection-bin
> by name (not just via a virtual package), would that help?

I think that would do it, deps there are:

python3 (<< 3.13), python3 (>= 3.12~), python3:any

The problem is, that the -bin package is new and that no rdeps know 
about it yet.