[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 ]=-
Attachment:
pgpfa10IbTOao.pgp
Description: PGP signature