These are executable scripts which start with the magic string "#!".
If a script invokes /usr/bin/pythonX.Y,
then the version supported by the source package
(XS-Python-Version or
debian/pyversions) should be restricted
to X.Y, assuming that the field is being provided. Or else,
it should be set to the list of python versions that the
script can support, or "all".
[1]
If there are separate scripts that invoke different versions
of Python, then all these versions must be in the
Depends field -- if you still want to continue
packaging instead of just shooting the upstream.
No script must use /usr/bin/python if it needs a Python version strictly greater or strictly lower than the current version.
These are python source code files that live in a private directory. If a package contains a private pure Python module, only one Python version may be supported, even if the private module can be recompiled for any new version of Python.
Any directory in which private pure Python modules are placed should be remembered, and the modules byte-compiled on installation. This is done automatically if one uses python-central, python-support uses the information in the file /usr/share/python-support/$package.dirs for a list of directories to scan.
The version supported by the source package (XS-Python-Version or debian/pyversions) is either the specific version of Python supported, or "all" [2] , if there are no specific restrictions based on Python version.
This should be set to "all" [3] if there are no specific restrictions based on Python version. Note that presence of private extension modules in the same package would mean that there are restrictions on the XB-Python-Version field.
If only a subset of Python versions are supported by the package, then the list of versions supported should be used [4]
These are compiled files linked to python libraries, and kept in a private directory. Since these files are compiled with one specific version of python, and do not live in versioned directories, only one version of python is supported at any given time.
The version supported by the source package (XS-Python-Version or debian/pyversions) is either the specific version of Python supported, or "all" [5], if there are no specific restrictions based on Python version.
If a single version of Python is supported, then the version supported by the binary package (XB-Python-Version field or the file .versions) is set to that version (copied from XS-Python-Version). If the current default version of Python is not supported, this field it set to the minimum version of Python actually supported by the module. If the current default version of Python is supported (or there are no restrictions on the version of python supported), then this field is set to the current version.
Public modules should be packaged with a name of python-foo, where foo is the name of the module. Such a package should support the current Debian Python version, and more if possible.
There are two kinds of public pure Python modules, the most common being the variety that live in unversioned public module directories, and, in rare cases, pure python modules that live in versioned public module directories. The latter is usually the case when the pure Python module imports an public extension module from the same directory, and thus the public extension and pure python modules must be in the same directory. Otherwise, pure python modules should live in an unversioned public module directory.
Depending on the packaging utility used, the modules live in either /usr/share/python-central or in /usr/share/python-support/$package.
Pure Python modules belonging to the core Python package generally live in a different set of directories than unofficial ones, but are otherwise treated exactly like other public pure Python Module which live in unversioned directories as detailed below.
In the common case of pure Python modules in unversioned public module directories, tools exist to help byte compile the pure Python modules for all versions of Python installed on the target system. In case of pure Python modules in versioned public module directories, byte compilation is up to the package scripts.
For the source package, this should be the version of Python supported, or "all", if there are no specific restrictions based on Python version. In case of pure Python modules in versioned public module directories, the set of versions supported usually corresponds to the list of versioned directories in which pure Python modules live.
Dependencies for the package also differ slightly based on whether the pure Python module is version dependent or not.
In the common case of pure Python modules in unversioned public module directories,
If there is a minimum supported version,
If the minimum version supported is less than or equal to the current version, then depend on python (>= $min_version)
Or else, if the minimum version supported is greater than the current version, then depend on python (>= $min_version) | python$min_version
If a upper bound of the supported versions exists, then the stop version is the next minor version after the maximum supported version (found by incrementing the minor version), whether or not it exists, and is form of Major.Minor. If there is an upper bound on the supported versions, and the upper bound is greater than or equal to the current version, then depend on python (<< $stop_version)
If the current version is higher than any supported version, then this package is obsolete. However, the following dependencies are still valid, if the corresponding lower and upper bounds of supported versions exist. python (>= $min_version) | python$min_version, python (<< $stop_version)
In case of pure Python modules in versioned public module directories, the set of versions corresponding to the list of versioned public module directories in which pure Python modules live is used in lieu of the value of XS-Python-Version.
If the lowest version in the set is less than or equal to the current version, then depend on python (>= $min_version)
Or else depend on python (>= $min_version) | python$min_version,
If the highest version in the set is greater than or equal to the current version, then depend on python (<< $stop_version) where the stop version is the next minor version greater than the highest supported version.
For every version in the set, also depend on python$version
Public extensions should be packaged with a name of python-foo, where foo is the name of the module. Such a package should support the current Debian Python version, and more if possible.
Depending on the packaging utility used, the modules live in either /usr/lib/pythonX.Y/site-packages or in /usr/lib/python-support/$package/pythonX.Y, with proper symbolic links in place.
The versions supported by the source and binary packages should be set to the list of versions for which the compiled extension modules are provided.
For every version of Python for which compiled extension modules are provided, provide a package named pythonX.Y-foo (assuming that the package name is python-foo).
| [1] | If the package uses python-central, and if there is no other value for the versions (set by any modules packaged), then the versions supported by the binary package (XB-Python-Version) is the same as above (XS-Python-Version, if XS-Python-Version is not empty, or "all", if it is empty). |
| [2] | If using python-central, use the special string "current" instead of "all". |
| [3] | If using python-central, use the special string "current" instead of "all". Note that if the package contains private extension modules, then the rules for setting XB-Python-Version for the private extension modules take precedence. |
| [4] | python-central differs here. If the current version is supported, then XB-Python-Version should be set to "current". If the current version is not supported, and if the minimum version supported is strictly higher than the current version, the XB-Python-Version field should be set to the minimum version supported. Failing that, if the current version is not supported, and the max version is lower than the current version, then this package should be deprecated, and is obsolete. |
| [5] | If using python-central, use the special string "current" instead of "all". |