[Pierre Habouzit, 22.03.2007] > On Thu, Mar 22, 2007 at 12:23:59AM +0100, Piotr Ożarowski wrote: > > [Steve Langasek, 21.03.2007] > > > On Wed, Mar 21, 2007 at 10:59:40PM +0100, Piotr Ożarowski wrote: > > > > I think depending on python-dev for current only modules/apps and > > > > python-all-dev for the rest should be enough (if both systems will > > > > recognize it correctly, I mean also: "python-dev(>=2.5)|python2.5-dev" ) > > > > > > No, this has nothing to do with the question of being able to get the > > > version number of, and build binary extensions for, the current version of > > > python. > > > > how about this: > > ^^^^^^^^^^^^^^^ > > > > case 1: emma - python application that installs private module > > Build-Depends: python-dev (>= 2.5) | python2.5-dev > > XS-Python-Version: >=2.5 > > > > Architecture: all > > > > case 2: emma - python application that installs private module (and lets > > say it is providing private python extension as well) > > Build-Depends: python-dev (>= 2.4) | python2.4-dev > > XS-Python-Version: >=2.4 > > > > Architecture: any > > > > > > case 3: sqlalchemy - python module > > Build-Depends: python-all-dev > > XS-Python-Version: >=2.3 > > > > Architecture: all > > > > case 4: pywavelets - python extension > > Build-Depends: python-all-dev > > XS-Python-Version: >=2.4 > > > > Architecture: any > > > > > > and I expect python-<system> to: > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > > > case 1: > > * compile it for current Python version only (no binNMU needed after > > default Python version change, just recompile the module on user's > > machine) > > for a pure module or a binary one ?
I mean just recompile .pyc files (for new default Python version), leave package untouched > > * set XB-Python-Version to "current, >2.5" # here "current" can't be > > deprecated, > > but this field should be filled automatically (think ${python:Versions}) > > so maintainer doesn't have to know about "current" > > current, > 2.5 has no sense at all, at least today, as current is > (today) meaning: please build that for python2.4 How will python-<system> know to recompile it just for one version and not for all supported ones? > > > * change hashbang if needed (and remember about it [also in in > > XB-Python-Version > > probably] - what if Python version from versioned hashbang will be > > removed from supported Python versions?) > > hashbang should always be /usr/bin/python as soon as the default > version is supported. We implicitely assume that as soon as a X.Y python > is supported, next version will. This is safe for 99% of the packages. > > But IMHO the new policy doesn't help you if your package doesn't > support the current default python. I mean, there is obviously tricks in > the debian/rules that are possible to render the package binNMUable, but > I don't think the dh_py* tools can help here. But I may be mistaken. What if my application needs python2.X where X = Y+1 and Y is default one? (I had this problem with gaupol when python2.3 was default, and "current, >2.4" worked just fine!) > > case 3: > > * build for all supported python versions (that are >=2.3) > > * set XB-Python-Version to ">2.3" (or "2.3-") > > * no binNMU needed, just recompile after `pyversions -s` will change > > no recompilation is needed in that case, even if pyversions -s > changes. I mean recompile pyc files only of course, not the whole package (as I said: no binNMU ) > > case 4: > > * as above, binNMU needed > > * XB-Python-Version: >=2.4 > > * Provides: python2.4-wavelets > > no binNMU is needed here either for a default python change. It is > recommended for a python version removal (to avoid to waste space) and > needed for the introduction of a new python (to support the new one). new supported python version is available, package provides .so files and you say no binNMU is needed? -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=-
pgpK5zbY9XiLN.pgp
Description: PGP signature