On Tue, Aug 22, 2006 at 12:42:03AM +0200, Josselin Mouette wrote:
> Le mercredi 16 ao�t 2006 � 11:34 +0200, Brian Sutherland a �crit :
> > smart-notifier has XS-Python-Version set to 2.4 but the binary
> > package gets Python-Version "current" if built with python2.4 as the
> > default python.
> >
> > In my tests with python2.3 as the default, Python-Version is set to 2.4.
> >
> > In both cases there is no python dependency (only python2.4).
> >
> > So anyone installing smart-notifier built with python2.4 as the defualt
> > on a machine with python2.3 as the default experiences breakage when
> > python-central tries to compile the bytecode for python2.3.
> >
> > It seems to me that dh_python should set Python-Version to x.y if
> > XS-Python-Version is x.y regardless of what the current default python
> > is. At least that is what I would have expected.
>
> This is one of the reasons why I don't like the X?-Python-Version
> fields. There is no way for the build process to tell between those two
> cases:
> 1. building for python2.4 only as we build for one version only and
> python2.4 is the default version;
> 2. building for python2.4 only as this is the only supported
> version.
Does this not work for case 1:
XS-Python-Version: current
and for case 2:
XS-Python-Version: 2.4
> If we apply the solution you describe, case 2 will be fixed, but case 1
> will break: when upgrading the default python interpreter, the module
> will not be available for the new version.
>
> Thus, we need separate interfaces to tell the helper tools about that.
> The -V flag was reintroduced in dh_pysupport (in 0.4) to fix this case,
> and I believe something similar should be done in dh_pycentral as well -
> dh_python is doomed to be removed anyway.
Yep, with the latest strategy of dh_python, this is probably a
python-central bug and has very little to do with dh_python or
python-support.
--
Brian Sutherland
Metropolis - "it's the first movie with a robot. And she's a woman.
And she's EVIL!!"
