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 madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgpVm0OMO3m3j.pgp
Description: PGP signature