I've attached a patch (it's built on the last one I sent) that attempts to clarify policy around packages that only work with specific versions of Python/Python3. Here's what I attempted to do: - Changed should support the default version to should support all supported versions. - Dropped the requirement that version specific packages can't depend on python-foo packages. They should use version specific packages when they are available, but it's reasonably safe to depend on a version independent package if a version specific one isn't provided. I think this is reasonably safe because if the upstream code in two packages don't run on the same python version, then they generally won't depend on each other. There is some small risk of a temporary impedence mismatch here, but Python release cycles are long enough that I don't think the risk is worth the trouble of maintaining the requirement that version specific Provides: be added on request. - Dropped the requirement to add version specific Provides: be on request. - Made version specific provides a must for binary extenstions It was a generic should before and I'm trying to limit the Provides: to the case of binary extensions (which have to be rebuilt to support new versions) and the less common case of version specific modules. - Added a requirement that, for binary extensions, the Provides: can be updated via binNMU when supported versions changes. I think this (mostly) reflects current practice, but I'm interested in discussion. The main change here is to (hopefully) make it clearer that python:Provides virtually always pointless for arch all packages. Scott K
--- python-policy.new.txt 2012-03-16 23:46:06.460372010 -0400
+++ python-policy.newer.txt 2012-03-17 12:46:40.242988226 -0400
@@ -375,18 +375,17 @@
preferably be named `python-<foo>', if the module name allows, but
this is not required if the binary package ships multiple modules. In
the latter case the maintainer chooses the name of the module which
- represents the package the most. Such a package should support the
- current Debian Python version, and more if possible (there are several
- tools to help implement this, see Appendix B, `Packaging Tools'). For
- example, if Python 2.3, 2.4, and 2.5 are supported, the Python
- statement
+ represents the package the most. Such a package should support all
+ supported Debian Python versions, (there are several tools to help
+ implement this, see Appendix B, `Packaging Tools'). For example, if
+ Python 2.6, and 2.7 are supported, the Python statement
import foo
- should import the module when the user is running any of
- `/usr/bin/python2.3', `/usr/bin/python2.4', and `/usr/bin/python2.5'.
- This requirement also applies to extension modules; binaries for all
- the supported Python versions should be included in a single package.
+ should import the module when the user is running either
+ `/usr/bin/python2.6' or `/usr/bin/python2.7', This requirement also
+ applies to extensions; binaries for all the supported Python versions
+ should be included in a single package.
2.3. Specifying Supported Versions
@@ -423,12 +422,14 @@
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
- keyword "all" is limited to Python versions and must be ignored for
- Python 3 versions. Lists of multiple individual versions (e.g. 2.4,
- 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.
+ numbers is clearer than "all" and encodes more information. Because
+ packages are backported, "all" may be expected to include supported
+ versions in the Debian stable release. The keyword "all" is limited
+ to Python versions and must be ignored for Python 3 versions. Lists
+ of multiple individual versions (e.g. 2.5, 2.6, 2.7) work for
+ `XS-Python-Version' and will continue to be supported, but are not
+ recommended and are not supported by `X-Python-Version' or
+ `X-Python3-Version'.
The keyword "current" has been deprecated and used to mean that the
package would only have to support a single version (even across
@@ -441,34 +442,41 @@
transitions. This can be adequately accomplished by examining package
dependencies.
- If your package is used by another module or application that requires
- a specific Python version, it should also `Provide: python<X>.<Y>-foo'
- for each version it supports.
-
2.4. Dependencies
-----------------
Packaged modules available for the default Python version (or many
versions including the default) as described in Section 2.2, `Module
- Package Names' must depend on "`python (>= <X>.<Y>')". If they
+ Package Names' must depend on "`python (>= <X>.<Y>')". For Python 3
+ packages, a dependency on a sufficient version of `python3' is
+ adequate for packages that do not ship version specific code. If they
require other modules to work, they must depend on the corresponding
`python-foo'. They must not depend on any `python<X>.<Y>-foo'.
- Packaged modules available for one particular version of Python must
- depend on the corresponding `python<X>.<Y>' package instead. If they
- need other modules, they must depend on the corresponding
- `python<X>.<Y>-foo' packages, and must not depend on any `python-foo'.
+ Packaged modules and binary extensions available only for one
+ particular version of Python must depend on the corresponding
+ `python<X>.<Y>' package instead. If they need other modules, they
+ must depend on the corresponding `python-<foo><X>.<Y>' packages when
+ available instead of the `python-foo'. Cases where this is required
+ should be rare.
+
+ If packages depend only a specific `python<X>.<Y>' or on any
+ `python-<foo><X>.<Y>' when `python<X>.<Y>' is being dropped from the
+ set of supported versions, it will be removed. It is up to package
+ maintainers to not over-specify version specific dependencies that
+ complicate transitions.
2.5. Provides
-------------
- Provides in binary packages of the form `python-<foo>' must be
- specified, if the package contains an extension for more than one
- python version. Provides should also be added on request of
- maintainers who depend on a non-default python version. Provides are
- only for extensions, not modules.
+ Provides in binary extension packages of the form
+ `python-<foo>.<X>.<Y>' must be specified. For architecture dependent
+ packages (when the versions are not otherwise constrained by Section
+ 2.3, `Specifying Supported Versions') a binary NMU must be sufficient
+ to update the Provides after the list of supported versions has
+ changed. Provides are usually only for extensions, not modules.
2.6. Modules Byte-Compilation
Attachment:
signature.asc
Description: This is a digitally signed message part.