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 ? > * 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 > * 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. > case 2: > * as above, except binNMU is needed after default python version change, no > need > to remember hashbang change A default python change only requires to binNMU packages that have private binary modules. _or_ packages with binary extensions that were only built for the old default version and not others. So for your example, indeed, you have to build only for $(pyversions -s). > 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. > 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). -- ·O· Pierre Habouzit ··O [EMAIL PROTECTED] OOO http://www.madism.org
pgpz9r8cZemBg.pgp
Description: PGP signature