Bug#1026104: longstanding problem with dependencies of python3-numpy in testing

[Helmut Grohne <helmut@subdivi.de>]

Hi Matthew,

On Sat, Jan 07, 2023 at 05:06:50PM +0000, Matthew Vernon wrote:
> Sandro, would you be opposed to relaxing the Depends: to a Recommends: ? If
> you would be opposed, would you mind briefly explaining why, please?

I think this question was already posed by Simon McVittie and Sandro's
answer was:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945824#59
| numpy provides compiled extensions for all supported python3 versions,
| so it has to depend on all of them since an extension compiled for 3.8
| (as an example) needs to have a 3.8 runtime environment available to
| be able to be imported and used; and so for all the other versions.
| this is by design and wont change.

Ralf Jung and Vincent Lefevre weren't totally convinced given this
answer, but there is no further followup from Sandro.

I am also unconvinced by this reasoning, because extensions do not
usually depend on the relevant interpreters. However, Sandro also noted
that the objected dependency is likely rooted elsewhere:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945824#12
| this is likely an artifact of shipping f2py3.7 and f2py3.8 with a
| shebang referring directly to a versioned interpreter. that's always
| been the case with multiple interpreters.

Given a Recommends, we'd likely have to wrap these scripts in a way that
produces a useful error message. Has anyone seen a patch for making this
happen? Joachim, would you volunteer to write one?

I would also like to compare this to how we handle things in other
areas. A common complaint of users is that gcc tends to become huge
every once in a while. This is due to new gcc versions being initially
packaged unstripped in order to make ICEs debuggable from build logs. In
a stable release, they're always be stripped as expected. So this size
increase just affects the transition period. Thus far, we have tolerated
this behaviour of gcc.

At this time, I see:
 * A maintainer having given a reason for an unpopular packaging choice.
 * No convincingly good proposal for alternative behaviours (e.g.
   Recommends would yield bad error messages as is) and no satisfactory
   patch.
 * Prior art for similar behaviour.

Helmut