Path: csiph.com!weretis.net!feeder8.news.weretis.net!fu-berlin.de!bofh.it!news.nic.it!robomod From: Simon McVittie Newsgroups: linux.debian.maint.python Subject: Re: python3:Depends and :any Date: Tue, 06 Aug 2024 10:50:02 +0200 Message-ID: References: X-Mailbox-Line: From debian-python-request@lists.debian.org Tue Aug 6 08:40:35 2024 Old-Return-Path: X-Amavis-Spam-Status: No, score=-109.51 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, LDO_WHITELIST=-5, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001, USER_IN_DKIM_WELCOMELIST=-0.01, USER_IN_DKIM_WHITELIST=-100] autolearn=ham autolearn_force=no MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Debian-User: smcv X-Mailing-List: archive/latest/22219 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/ZrHhcZTMWflTBEuI@remnant.pseudorandom.co.uk Approved: robomod@news.nic.it Lines: 47 Organization: linux.* mail to news gateway Sender: robomod@news.nic.it X-Original-Date: Tue, 6 Aug 2024 09:40:17 +0100 X-Original-Message-ID: X-Original-References: <87ttfymila.fsf@secretsauce.net> Xref: csiph.com linux.debian.maint.python:16181 On Tue, 06 Aug 2024 at 10:32:49 +0700, Dima Kogan wrote: > 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