Python MultiArch Installation

See Python/Python3.3 for general issues with Python 3.3. See Multiarch for general information on the Debian multiarch effort.

PythonX.Y packages

The experimental release has Python3.3 and Python2.7 packaged for installation as a Multi-Arch package. There is no plan to provide the multiarch installation for 2.6 and 3.2; these python versions need to be dropped first in jessie.

The packages pythonX.Y-minimal, pythonX.Y, pythonX.Y-dev and pythonX.Y-dbg are split, the library parts are now found in the packages libpythonX.Y-minimal, libpythonX.Y-stdlib, libpythonX.Y-dev and libpythonX.Y-dbg. Package build-dependencies and dependencies do not have to be changed for package builds for now. The new lib* packages are Multi-Arch: same, the existing pythonX.Y packages are now Multi-Arch: allowed.

Some installation paths and file names are changed:

Python defaults packages

The defaults packages for python, python-dev, python-dbg need to become Arch: any packages, Multi-Arch: allowed.

Python code

In general you should *not* rely on the multiarch tuple in your Python code. Build dependencies on the multiarch tuple may be fine, however runtime dependencies on the multiarch tuple are not. If you need to use the tuple, here you go (note that this is not upstream but Debian specific):

The preferred solution is to use the MULTIARCH config variable. Note: this will appear upstream in 2.7.4 and 3.3.1.

>>> import sysconfig
>>> sysconfig.get_config_var('MULTIARCH')

If this doesn't work for you, you can use a different approach (note this is broken for cross builds by design). The location is different in Python 2 and Python 3. In Python 2, you can use

>>> import sys
>>> sys._multiarch

In Python 3.3+, PEP 421 defines where this information should live:

>>> import sys
>>> sys.implementation._multiarch

For bilingual code, use:

>>> triplet = getattr(sys, 'implementation', sys)._multiarch

Third party modules

Extension modules can be made Multi-Arch same, if it doesn't have any file conflicts. Normally that does mean to rename the files for extension modules (Note: dh_python3 and dh_python2 both now do this renaming automatically).

If an architecture dependent python-foo (Multi-Arch: same) package depends on a binary independent python-bar package, this python-bar package has to be made Multi-Arch: allowed.

Currently known issues:

Cross builds

Currently just the python2.7 and python3.3 packages can be cross-built. Most python build systems are not yet ready for cross builds.

distutils and setuptools

The basic idea to cross-build packages is to have the libpythonX-dev as build dependencies for the host/target, and the python interpreters available for the build machine.

Build-Depends: libpython3-all-dev, libpython3-all-dbg,
 libpython-all-dev, libpython-all-dbg,
 python3-all-dev:any, python3-all-dbg:any,
 python-all-dev:any, python-all-dbg:any,

Make the build aware of the cross build in debian/rules:

include /usr/share/dpkg/
  SET_CROSS_ENV = PYTHONPATH=/usr/lib/python$$pv/plat-$(DEB_HOST_MULTIARCH)

  # FIXME: is this sufficient?

Then use it in each call to

        set -xe; for pv in $(shell pyversions -vr); do \
                $(SET_CROSS_ENV) python$$pv build; \

Setting PYTHONPATH to the platform directory for the host let's the build python find the _sysconfigdata for the host. Setting _PYTHON_HOST_PLATFORM overwrites the value return by get_platform(). There are some caveats:

This should build at least simple extensions, however dh_python3 isn't yet aware of cross builds and renames the 3.3 extensions to the build multiarch name. dh_python2 doesn't rename anything at the moment.

For an example using dh_python[23] see, for an example manually installing and renaming the extensions, see the python{,3}-stdlib-extension packages in Ubuntu raring.

The support for _PYTHON_HOST_PLATFORM is found upstream starting with 3.3.0, and backported in Debian to 2.7.3-15.