On Thu, Mar 22, 2007 at 12:53:27AM +0100, Piotr Ożarowski wrote:
> [Pierre Habouzit, 22.03.2007]
> > On Thu, Mar 22, 2007 at 12:23:59AM +0100, Piotr Ożarowski wrote:
> > > * 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?
Why would you prevent the user to bytecompile your package for every
python version he choose to install ? I see the point to avoid archive
bloat in not building every binary extension. But locally ? Well, that
seems wrong. Really.
Especially since the dh_py* tools will only byte-compile code for
python versions that are supported _and_ installed on the user machine.
For pure python packages "current" does not makes sense.
> > > * 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!)
then you ask for 2.4- and the dh_* tool will deal with things for the
dependencies. It's up to you to fix the hashbangs properly. But again,
dh_py* tools won't help you a lot for packages that do not _at least_
support pyversions -d. You will need to do some extra work.
But IMHO the whole point of that policy is that a move to a new python
(python2.5 here) can be done very fast, before there is too many
packages that only work with python2.5, meaning that there will be few
packages in that case, and that it will only be a transitionnal
situation for them.
> > > 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?
You definitely seem to have misread me.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgpmitz0JPHwp.pgp
Description: PGP signature