<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, 25 Aug 2018 at 05:07, Steve Langasek <<a href="mailto:steve.langasek@ubuntu.com">steve.langasek@ubuntu.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Andreas,<br>
<br>
On Fri, Aug 24, 2018 at 10:05:23AM -0300, Andreas Hasenack wrote:<br>
> Hi,<br>
> <br>
> while investigating some DEP8 failures currently in cosmic's<br>
> migration, I came across this:<br>
> $ dpkg -s python3-numpy|grep Depends<br>
> Depends: python3 (<< 3.8), python3 (>= 3.6~), python3.6:any,<br>
> python3.7:any, python3:any (>= 3.3.2-2~), libblas3 | libblas.so.3,<br>
> libc6 (>= 2.27), liblapack3 | liblapack.so.3<br>
> <br>
> Is it ok/correct to depend on two python versions like that? Is the<br>
> point of it making sure numpy is available regardless which python 3<br>
> you are using? But at the cost of pulling in both?<br>
> <br>
> This is breaking python3-libcloud, which does not support python3.7,<br>
> when pulled in via fdroidserver:<br>
> <a href="https://pastebin.ubuntu.com/p/Kn77DXfxR5/" rel="noreferrer" target="_blank">https://pastebin.ubuntu.com/p/Kn77DXfxR5/</a><br>
> <br>
> The correct fix is to have python3-libcloud work with python 3.7, by<br>
> replacing "async" (a reserved keyword in python3.7) with something<br>
> else, like async_, but what caught my eye was this numpy dependency in<br>
> two python versions. And how libcloud ended up chosing 3.7 over 3.6<br>
> I'm not sure.<br>
<br>
This issue was reported in Debian during the previous python transition, and<br>
was closed without a permanent resolution:<br>
<br>
 <a href="https://bugs.debian.org/878281" rel="noreferrer" target="_blank">https://bugs.debian.org/878281</a><br>
<br>
And a bug is now open again about the same issue wrt the python3.7<br>
transition:<br>
<br>
 <a href="https://bugs.debian.org/903663" rel="noreferrer" target="_blank">https://bugs.debian.org/903663</a><br>
<br>
I agree that the current behavior is incorrect and not what we expect from<br>
packages that support multiple versions of python3.<br></blockquote><div><br></div><div>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?</div><div><br></div><div>Cheers,</div><div>mwh </div></div></div>