On Mon, Oct 31, 2011 at 22:07, Jakub Wilk <jw...@debian.org> wrote:
> * Sandro Tosi <mo...@debian.org>, 2011-10-31, 19:57:
>>>
>>> Dependencies generated by dh_numpy
>>> ==================================
>>> dh_numpy would generate dependency either on "python-numpy-abi$N" (by
>>> default) or on "python-numpy-api$N" (if a special option, say, --strict, is
>>> used).
>
> I just realized that, in order to make packages using Cython happy, the
> first one will have to be:
>
> "python-numpy-abi$N, python-numpy (>= $V)"
>
> where $V is the first version with the current API. [0]
Mh ok, so we need to keep 3 versions information: the ABI $N , the API
$N , and the version $V that introduced API $N - did I get it
correctly?
re big C_ABI_VERSION, I've asked upstream and they tell me that
originally it was the numpy version, and it got that big when 1.0 API
was released (each piece of the number is a piece of the version);
they are currently increasing it one by one, so we can start with 9
(and 6 for API).
> It'd quite crazy, but in theory, yes, that could happen.
>
>> how would you imagine to handle this? with "dh_numpy -pbin1
>> --strict\ndh_numpy -pbin2"
>
> Exactly.
good
>>> Avoiding strict dependencies for arch:all packages
>>> ==================================================
>>> dh_numpy should not generate any dependencies in arch:all packages. Such
>>> packages cannot rely on Numpy ABI, and rebuilding them for transition
>>> purposes is causes lot of trouble. (We already had to do this in the past!)
>>> For the same reason, /usr/share/python/dist/python-numpy needs to go away.
>>
>> so just a python-numpy added to python:Depends?
>
> I was rather thinking about not touching such packages at all. But adding
> unversioned python-numpy to ${python:Depends} would work, too.
yeah, I was thinking more like "put dh_numpy in the loop and it'll do
the right thing no matter the bin pkgs you have".
>> how does it fix with a source that generates an arch:all and an arch:any
>> (the latter using either -abi or -api)?
>
> dh_numpy would generate different substitutions for each of them. I don't
> see any problem here.
yeah I see
>>> Gracefully handling the upcoming transition
>>> -------------------------------------------
>>> A number of packages in the archive already has dependency on
>>> "python-numpy (<< 1:1.6)", which is not satisfiable by the package in
>>> experimental. To avoid this transition (or at least reduce its size) we
>>> could do one of two things:
>>> 1) Implement the proposed changes first in unstable, schedule binNMUs,
>>> then upload Numpy 1.6 to unstable.
>>> 2) Implement the proposed changes only for Numpy 1.6, but make dh_numpy
>>> generate alternative versioned dependencies:
>>> "python-numpy (>= 1:1.5.1), python-numpy-abi$N | python-numpy (<<
>>> 1:1.6.2)".
>>> Then upload Numpy 1.6, schedule binNMUs.
>>
>> Mh, my lazy instinct would say 2) that has also the advantage to bring
>> 1.6 into unstable (but I guess 1.7 is coming soon).
>
> Yeah, that option sounded very appealing, but turned out not feasible after
> all. See my comment about Cython at the top of this mail. C_API_VERSION has
> been bumped from 4 to 6, so $V should be at least >= 1:1.6.
Ok, so we should start like this:
- implement this proposal in the version currently in sid
- round of binNMUs
- wait for transition to testing?
- port the code to 1.6.1 package in experimental
- upload it to sid
- reiter
is that correct?
>> Please also note taht my perl foo is barely None, so I'd need some help in
>> extending dh_numpy :)
>
> No problem, I can do the coding part once we agree how everything should
> work. :)
Thanks about that! :)
Cheers,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
_______________________________________________
Python-modules-team mailing list
Python-modules-team@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/python-modules-team
