Raphael Hertzog writes:
> On Tue, 20 Jun 2006, Raphael Hertzog wrote:
> > On Tue, 20 Jun 2006, Raphael Hertzog wrote:
> > > On Mon, 19 Jun 2006, Raphael Hertzog wrote:
> > > > - pyversions needs to be modified to not fail if the field
> > > > XS-Python-Version is not present. He should in that case
> > > > use the information of the debian/pyversions file. I will
> > > > hopefully soon provide a patch for this.
> > >
> > > Here's a patch and the resulting pyversions script. For packages not using
> > > XS-Python-Version, they can do "pyversions -r debian/pyversions" and get
> > > the list of python packages to build with.
> >
> > I've slightly updated the patch so that if someone is doing "pyversions -r
> > debian/control" and if it would fail, then it tries "debian/pyversions"
> > before failing.
>
> Okay yet another update (the last... I promise). Instead of requiring a
> parameter you can now call "pyversions -r" and in that case it will check
> first for the field in debian/control and then try with debian/pyversions
> and if nothing is found, then it will return all the supported versions.
>
> Updated files attached.
>
> Matthias, this time you can safely integrate this version in the official
> python package.
The patch itself looks ok to me.
Maybe you could help me in understanding what "the result of messing
up with dpkg's database and control fields" mentioned in [1] has to do
with the added XS-Python-Version field. Leaving out this field before
we started using it for transitions makes it less useful. If a maintainer
wants the primary source of information to be the debian/pyversions
field, then please make sure that a XS-Python-Version:
${python:SourceVersions} variable is generated by dh_python and can be
brought into the Sources file of the distribution.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
