[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
