python3:Depends and :any

[Dima Kogan]

Hi.

I'm looking at making packages depending on python3-numpy
cross-buildable. Often this means splitting python3-numpy into a
separate python3-numpy-dev that is Multi-Arch:same. But in this case it
looks like you can ALMOST get away with a single python3-numpy package;
with some tweaks it can be Multi-Arch:same. The last sticking point is
the python3:Depends subst var, so I'm asking here.

As with most packages, python3-numpy has

Depends: ${python3:Depends}

which today expands to

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

Can somebody comment about why the :any is on the un-versioned
dependency only? Adding the :any to the other two would fix my problem,
and I'd like to get that added if there isn't a strong reason not to.

Thanks!

[Simon McVittie]

Post by Dima Kogan
As with most packages, python3-numpy has
Depends: ${python3:Depends}
which today expands to
Depends: python3 (<< 3.13), python3 (>= 3.12~), python3:any
Can somebody comment about why the :any is on the un-versioned
dependency only? Adding the :any to the other two would fix my problem,
and I'd like to get that added if there isn't a strong reason not to.

I'm guessing you want this because in a cross-compiling scenario, for
example build=amd64 and host=riscv64, you want to be able to install
python3:amd64 (to be able to run Meson, etc.) together with
python3-numpy:riscv64 (so riscv64 code can find numpy.pc)?

If python3-numpy contained "pure Python" then python3:any would be enough.
python3-six is a good simple example of a package in this situation.

But if python3-numpy contains native-code (compiled C/C++/etc.)
extensions, then that would be incorrect, because a compiled riscv64
extension cannot be loaded into an amd64 interpreter, and will
fail if you try; so it would be wrong to allow python3:amd64 and
python3-numpy:riscv64 to be installed together.

It appears that python3-numpy *does* contain native code, for example
/usr/lib/python3/dist-packages/numpy/core/_simd.cpython-312-x86_64-linux-gnu.so.
So the dependency on python3 of the same architecture is correct. This is
also why the dependency has to be versioned: the current numpy binaries
in unstable would not work correctly with Python 3.11 or 3.13, even if
the source does, because the binary package doesn't have *-311-*.so or
*-313-*.so (when Python 3.13 becomes a supported version, *-313-*.so
will be added by a binNMU).

I think you will need to introduce a python-numpy-dev or
python3-numpy-dev that is Architecture:any,Multi-Arch:same, or possibly
Architecture:all,Multi-Arch:foreign if its contents can easily be
made architecture-independent (this only works if the .pc file is
the same for every architecture because it only refers to headers
in /usr/include and not libraries, in which case it can be moved to
/usr/share). You might find that python3-talloc-dev is useful prior art
for the Architecture:any,Multi-Arch:same case, and python-dbus-dev is
an example of the Architecture:all,Multi-Arch:foreign case.

smcv

[Dima Kogan]

Hi Simon.

Thanks for the detailed reply. The current expansion

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

has dependencies both with and without :any. Is THAT right?

In any case, I'm going to propose a python3-numpy package split.

Thanks much.

[Simon McVittie]

Post by Dima Kogan
Thanks for the detailed reply. The current expansion
Depends: python3 (<< 3.13), python3 (>= 3.12~), python3:any
has dependencies both with and without :any. Is THAT right?

Sort of. Let me put it this way: I don't think it's wrong.

A dependency on python3:any is *mostly* redundant with a dependency
on python3 (which is "stronger": if you have python3, implicitly of
the same architecture as the package that has the dependency, then you
certainly have python3:any), so you might expect those dependencies to
be simplified down to

Depends: python3 (<<...), python3 (>=...),

the same way that if you have

Depends: foo, foo (>= 1), foo (>= 2)

it gets simplified down to just foo (>= 2).

But python3:any is not *technically* redundant with python3, because
a dependency on python3 could hypothetically be satisfied by a python3
package that was Multi-Arch: no|same|foreign, whereas a dependency on
python3:any can only be satisfied by a python3 package that is
Multi-Arch: allowed.

In fact python3 *is* Multi-Arch: allowed, but there was a time when it
wasn't, and dpkg can't know that it always will be in the future.
So removing python3:any from the Depends would technically change its
meaning, with the result that dpkg doesn't optimize it away.

smcv