On Sat, 25 Aug 2018 at 05:07, Steve Langasek <email@example.com> wrote:
On Fri, Aug 24, 2018 at 10:05:23AM -0300, Andreas Hasenack wrote:
> while investigating some DEP8 failures currently in cosmic's
> migration, I came across this:
> $ dpkg -s python3-numpy|grep Depends
> Depends: python3 (<< 3.8), python3 (>= 3.6~), python3.6:any,
> python3.7:any, python3:any (>= 3.3.2-2~), libblas3 | libblas.so.3,
> libc6 (>= 2.27), liblapack3 | liblapack.so.3
> Is it ok/correct to depend on two python versions like that? Is the
> point of it making sure numpy is available regardless which python 3
> you are using? But at the cost of pulling in both?
> This is breaking python3-libcloud, which does not support python3.7,
> when pulled in via fdroidserver:
> The correct fix is to have python3-libcloud work with python 3.7, by
> replacing "async" (a reserved keyword in python3.7) with something
> else, like async_, but what caught my eye was this numpy dependency in
> two python versions. And how libcloud ended up chosing 3.7 over 3.6
> I'm not sure.
This issue was reported in Debian during the previous python transition, and
was closed without a permanent resolution:
And a bug is now open again about the same issue wrt the python3.7
I agree that the current behavior is incorrect and not what we expect from
packages that support multiple versions of python3.
So the problem is that python3-numpy contains a version of 'f2py' for each supported version of Python. I guess the proper fix involves creating a separate package for the each version of f2py? python3.6-f2py, python3.7-f2py, and have python3-numpy depend on the one for the default version of Python?