I've worked on a couple of dh_python3 bugs in the last few days and as a result, gotten my hands dirty on the Python 3 dependency generation code.
This caused me to consider the question of specifying which Python 3 versions are supported by a package a little more closely. I have generally considered that if all Python (Python 3) versions supported in the development release were supported by the package, then there's no need to explicitly define the supported versions in the packaging (e.g. using X-Python-Version). Reality is, of course, slightly more complex. For Python 3, architecture independent packages that have no version specific code in them will always depend on python3 >= 3.1.3-13~. So for these packages the minimum version requirement specified in X-Python3-Version isn't 3.2 (the current version in Wheezy), it's 3.1. Packages that will only work with Python 3 3.2 need this specifed in X-Python3-Version. I took a stab at adding some words to the Python policy to explain this. Comments please (diff attached). Scott K
--- python-policy.txt 2012-03-16 23:29:14.384401914 -0400
+++ python-policy.new.txt 2012-03-16 23:46:06.460372010 -0400
@@ -398,16 +398,29 @@
Python 3) supported by the source package. Similarly,
`X-Python3-Version' is used to specify the versions of Python 3
supported by the package. When not specified, they default to all
- currently supported Python (or Python 3) versions. They are used by
- some packaging scripts to automatically generate appropriate Depends
- and Provides lines. The format of the field may be one of the
- following:
+ currently supported Python (or Python 3) versions.
+
+ They are used by some packaging scripts to automatically generate
+ appropriate Depends and Provides lines. The format of the field may
+ be one of the following:
XS-Python-Version: >= X.Y
XS-Python-Version: >= A.B, << X.Y
XS-Python-Version: A.B, X.Y
XS-Python-Version: all
+ If the package supports all versions of Python/Python3 either
+ supported in or planned for the development release, as well as the
+ stable release, then `X-Python-Version' or `X-Python3-Version' may
+ generally be omitted from `debian/control'. The most common exception
+ to this is architecture independent Python 3 modules with no version
+ specific code. Since, unlike in Python, version specific directories
+ are not needed for Python 3, there is no need to constrain their
+ minimum Python 3 version to the supported versions. For these
+ packages, `X-Python3-Version' can only be omitted if the package
+ supports python3 >= 3.1.3-13 and later (python3 3.0 was never a
+ "supported" Python 3 version in Debian).
+
The keyword "all" means that the package supports any Python version
available but might be deprecated in the future since using version
numbers is clearer than "all" and encodes more information. The
@@ -416,6 +429,7 @@
2.5, 2.6) work for `XS-Python-Version' and will continue to be
supported, but are not recommended and will not be supported by
`X-Python-Version' or `X-Python3-Version' after the Squeeze release.
+
The keyword "current" has been deprecated and used to mean that the
package would only have to support a single version (even across
default version changes). It must be ignored for Python 3 versions.
signature.asc
Description: This is a digitally signed message part.
