Report on the situation of python2.5 in Debian

[Aaron M. Ucko]

[-release dropped, as this subthread is no longer on topic.]

Josselin Mouette <joss@...> writes:

> If anyone has ideas about how to deal with such cases, I'm all open for
> implementing them. It would be easy for python-support to maintain a
> list of files that should be symbolic links to the version linked
> against the current python. The difficulty is about where to install
> those files in the packaging process so that dh_pysupport sees them.

I was actually somewhat more concerned about getting a sane
${python:Depends} setting, but that's definitely also an issue.

--
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?amu@...


--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Steve Langasek]

On Fri, Oct 05, 2007 at 08:04:27PM +0200, Josselin Mouette wrote:
> I cannot say that the situation looks good. Since the last transition,
> many new packages have been introduced, and a large part of them don't
> support the current policy. Another bad news is that it isn't possible
> to rely on the packages' metadata, as many maintainers don't understand
> what the X?-Python-Version fields mean.

> Let's start with the good news. The following packages are included in
> python2.5, and will disappear or become legacy.
>         celementtree
>         ctypes
>         python-pysqlite2
>         python-wsgiref

> The following packages need a round of binNMUs as soon as possible, to
> build extensions for python2.5, after which they shouldn't bother us.
> Can anyone schedule the binNMUs please?

Is there code available that can be used to reproduce this list from
Packages/Sources?  I would very much prefer to be able to generate an
authoritative list of per-arch binaries that need to be binNMUed, so that
the progress can be tracked and so we're not needlessly binNMUing packages
that have sourceful uploads first.

--
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
vorlon@...                                   http://www.debian.org/


--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Josselin Mouette]

Le vendredi 12 octobre 2007 à 22:40 -0700, Steve Langasek a écrit :
> Is there code available that can be used to reproduce this list from
> Packages/Sources?  I would very much prefer to be able to generate an
> authoritative list of per-arch binaries that need to be binNMUed, so that
> the progress can be tracked and so we're not needlessly binNMUing packages
> that have sourceful uploads first.

Given the number of packages that don't follow the policy or declare
wrong values in XS-Python-Version, for most packages it was possible to
decide only by looking at debian/rules by hand.

--
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.

[Bernd Zeimetz]

> Given the number of packages that don't follow the policy or declare
> wrong values in XS-Python-Version, for most packages it was possible to
> decide only by looking at debian/rules by hand.

Policy does not require to set XS-Python-Version except for pycentral -
at least that's how Manoj[1] and myself seem to understand [2]. It is
only appreciated to set it for all packages. It would make sense to make
setting XS_Python-Version a must or all packages which wouldn't have
'all' in there.


Cheers,

Bernd

[1]: http://people.debian.org/~srivasta/manoj-policy/x316.html#AEN328
[2]: http://wiki.debian.org/DebianPython/NewPolicy

--
Bernd Zeimetz
<bernd@...>                         <http://bzed.de/>


--
To UNSUBSCRIBE, email to debian-python-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Josselin Mouette]

Le samedi 13 octobre 2007 à 18:29 +0200, Bernd Zeimetz a écrit :
> > Given the number of packages that don't follow the policy or declare
> > wrong values in XS-Python-Version, for most packages it was possible to
> > decide only by looking at debian/rules by hand.
>
> Policy does not require to set XS-Python-Version except for pycentral -
> at least that's how Manoj[1] and myself seem to understand [2]. It is
> only appreciated to set it for all packages. It would make sense to make
> setting XS_Python-Version a must or all packages which wouldn't have
> 'all' in there.

The problem doesn't lie in packages not having this field (which indeed
means "all"), but in packages having it but with a wrong value.

And anyway it doesn't help in determining whether an architecture: any
package can *correctly* build against several python versions.

--
 .''`.
: :' :      We are debian.org. Lower your prices, surrender your code.
`. `'       We will add your hardware and software distinctiveness to
  `-        our own. Resistance is futile.