Software: Apache/2.2.16 (Debian). PHP/5.3.3-7+squeeze19 

uname -a: Linux mail.tri-specialutilitydistrict.com 2.6.32-5-amd64 #1 SMP Tue May 13 16:34:35 UTC
2014 x86_64 

uid=33(www-data) gid=33(www-data) groups=33(www-data) 

Safe-mode: OFF (not secure)

/usr/share/doc/python/python-policy.html/   drwxr-xr-x
Free 129.74 GB of 142.11 GB (91.3%)
                            Encoder    Tools    Proc.    FTP brute    Sec.    SQL    PHP-code    Update    Feedback    Self remove    Logout    

Viewing file:     ch-module_packages.html (13.21 KB)      -rw-r--r--

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ A ] [ B ] [ C ] [ next ]

Debian Python Policy
Chapter 2 - Packaged Modules

The goal of these policies is to reduce the work necessary for Python transitions. Python modules are internally very dependent on a specific Python version. However, we want to automate recompiling modules when possible, either during the upgrade itself (re-byte-compiling pyc and pyo files) or shortly thereafter with automated rebuilds (to handle C extensions). These policies encourage automated dependency generation and loose version bounds whenever possible.

2.1 Types of Python Modules

There are two kinds of Python modules, "pure" Python modules, and extension modules. Pure Python modules are Python source code that works across many versions of Python. Extensions are C code compiled and linked against a specific version of the python runtime, and so can only be used by one version of Python. Some distributions link extensions to libpython, but this is not the case in Debian as symbols might as well be resolved by /usr/bin/pythonX.Y which is not linked to libpython.

Python packages are directories containing at least a __init__.py, other modules, extensions and packages (A package in the Python sense is unrelated to a Debian package). Python packages must be packaged into the same directory (as done by upstream). Splitting components of a package across directories changes the import order and may confuse documentation tools and IDEs.

There are two ways to distribute Python modules. Public modules are installed in a public directory as listed in Module Path, Section 1.5. They are accessible to any program. Private modules are installed in a private directory such as /usr/share/package-name or /usr/lib/package-name. They are generally only accessible to a specific program or suite of programs included in the same package.

2.2 Module Package Names

Public modules used by other packages must have their binary package name prefixed with python-. It is recommended to use this prefix for all packages with public modules as they may be used by other packages in the future. Python 3 modules must be in a separate binary package prefixed with python3- to preserve run time separation between python and python3. The binary package for module foo should 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 Packaging Tools, Appendix B). For example, if Python 2.3, 2.4, and 2.5 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.

2.3 Specifying Supported Versions

The optional X-Python-Version (preferred) or XS-Python-Version field in the general paragraph (the first one, for the source package) of debian/control specifies the versions of Python (not versions of 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:

     XS-Python-Version: >= X.Y
     XS-Python-Version: >= A.B, << X.Y
     XS-Python-Version: A.B, X.Y
     XS-Python-Version: all

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. 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. Python 3 versions should never have been used in XS-Python-Version and should be considered deprecated at best. X-Python3-Version should be used instead.

The binary package paragraphs of your debian/control file should also have a line:

     XB-Python-Version: ${python:Versions}

The python:Versions is substituted by the supported Python versions of the binary package, based on XS-Python-Version. (If you are not using python-central or python-support, you will need to handle this substitution yourself.) The format of the field XB-Python-Version is the same as the XS-Python-Version field for packages not containing extensions. Packages with extensions must list the versions explicitly.

If your package is used by another module or application that requires a specific Python version, it should also Provide: pythonX.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 Module Package Names, Section 2.2 must depend on "python (>= X.Y)". If they require other modules to work, they must depend on the corresponding python-foo. They must not depend on any pythonX.Y-foo.

Packaged modules available for one particular version of Python must depend on the corresponding pythonX.Y package instead. If they need other modules, they must depend on the corresponding pythonX.Y-foo packages, and must not depend on any python-foo.

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.

2.6 Modules Byte-Compilation

If a binary package provides any binary-independent modules (foo.py files), the corresponding byte-compiled modules (foo.pyc files) and optimized modules (foo.pyo files) must not ship in the package. Instead, they should be generated in the package's postinst, and removed in the package's prerm. The package's prerm has to make sure that both foo.pyc and foo.pyo are removed.

A binary package should only byte-compile the files which belong to the package.

The file /etc/python/debian_config allows configuration how modules should be byte-compiled. The postinst scripts should respect these settings.

Pure Python modules in private installation directories that are byte-compiled with the default Python version must be forcefully byte-compiled again when the default Python version changes. Public Python extensions should be bin-NMUed. Private Python extensions should be subject to binary NMUs every time the default interpreter changes, unless the extension is updated through a .rtupdate script.

[ previous ] [ Contents ] [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ] [ A ] [ B ] [ C ] [ next ]

Debian Python Policy