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
signature.asc
Description: This is a digitally signed message part.
