Re: Specifying Supported Python Versions - Round 2
Hi Scott,
thanks for bringing this up (again :) ).
On Wed, Jun 30, 2010 at 22:41, Scott Kitterman <debian@kitterman.com> wrote:
> As I had said I would after the last round, I asked the release team about any
> specific requirements they might have for Python version specification. They
> don't. My summary of the thread is "We want it to be easy". The thread
> starts here for those interested:
>
> http://lists.debian.org/debian-release/2010/06/msg00211.html
>
> Based on the previous discussion here and feedback on IRC, here is a revised
> proposal:
>
> For Python(2):
>
> pyversions -r will use (in this order):
>
> 1. A new field called X-Python2-Version: This is identical to the current XS-
> P-V, except it doesn't get exported to the source Packages.{gz,bz2}, and it
> does not support lists of versions (e.g. (2.4, 2.5, 2.6) is not supported).
> Acceptable values are a single version (e.g 2.6), greater than or equal to a
> version (e.g. >= 2.5), or strictly less than a version (e.g. << 2.7).
> Versions 3 or greater will raise an error.
Will this make XS-P-V a sort of "Deprecate"? I find the semantic of
X-P2-V clearer than XS-P-V, but I just want to know how hard are you
going to push it (if we're going to migrate to it, it requires a
change a lot of packages)
> 2. XS-Python-Version: The same as it is currently, except versions 3 or
> greater will raise an error. This will require at least two packages to have
> to be changed. I'd appreciate it if someone could check if anything other
> than python-apt and pyyaml are affected.
>
> 3. debian/pyversions: Same as XS-Python-Version.
Please, pretty please, can we drop support for it? Is that really an
hassle to remove it? Or there are some advantages of having it around
I don't see? There should be one, and possibly only one, way to
specify python versions.
> 4. Implicit "all" supported Python 2 versions (currently 2.5 and 2.6).
You mean not specifying any X-P2-V or XS-P-V, 'all' is implicitly used
for 2.x supported versions? I'd rather explicit than implicit, so
raise error if not present.
> For Python3:
>
> 1. A new field called X-Python3-Version: It does not support lists of
> versions (e.g. (3.0, 3.1)). Acceptable values are a single version (e.g 3.1),
> greater than or equal to a version (e.g. >= 3.1), or strictly less than a
> version (e.g. << 3.2). Versions 2 or less will raise an error.
>
> 2. There is no #2. If your build system uses py3versions -r, then you need
> X-P3-V, if it's not there, an error will be raised. If it doesn't use
> py3versions -r, then it's between the maintainer and their build system. The
> field is not mandatory.
both points fine for me.
Regards,
--
Sandro Tosi (aka morph, morpheus, matrixhasu)
My website: http://matrixhasu.altervista.org/
Me at Debian: http://wiki.debian.org/SandroTosi
Reply to: