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.
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.
4. Implicit "all" supported Python 2 versions (currently 2.5 and 2.6).
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.
This change will affect Debian Python Policy, pyversions, and py3versions. If
we get some consensus around this, I will prepare the changes.
Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.