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:

pyconfig.h is now located in /usr/include/<multiarch>/pythonX.Y<abitags>, the architecture independent parts stay in /usr/include/pythonX.Y<abitags>. Some configuration code will be broken by this change, because two directories need to be included. (An alternative to move all headers into the multiarch location does break almost the same configurations.) To fix these issues:
- Use pythonX.Y-config --includes (which includes both directories)
- Use pkgconfig --cflags python-X.Y (which includes both directories)
- If distutils/sysconfig/get_python_inc is used, use a second call, calling with plat_specific=1.
The config directory (still needed by some older extension modules) is now located in /usr/lib/pythonX.Y/config-X.Y<abitags>-<multiarch>. Use pythonX-Y-config --configdir to get the path. Note: This option is a backport, it appears upstream starting with 3.3.
The name of the plat-linux2 directory was changed to plat-<multiarch> (this should be transparent, as it is still found on sys.path).
Extensions are looked up in a multiarch specific filename, before looking in the default filename.
- For python2.7, foo.<multiarch>.so and foo.<multiarch>_d.so are used.
- For python3.3, foo.cpython-33m-<multiarch>.so and foo.cpython-33dm-<multiarch>.so are used.

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:

Making a third party module M-A: same still doesn't allow to install it (currently depends on python/python3 which is not Multi-Arch: same).
The dependency on python could be replaced by libpython-stdlib/libpython3-stdlib, however this doesn't guarantee yet that a python interpreter for byte-code compilation and removal is available.

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/architecture.mk
ifneq ($(DEB_BUILD_MULTIARCH),$(DEB_HOST_MULTIARCH))
  SET_CROSS_ENV = PYTHONPATH=/usr/lib/python$$pv/plat-$(DEB_HOST_MULTIARCH)

  # FIXME: is this sufficient?
  SET_CROSS_ENV += _PYTHON_HOST_PLATFORM=$(DEB_HOST_GNU_CPU)
endif

Then use it in each call to setup.py:

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

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:

Look at the outcome of the cross build, verbose build logs are helpful.
Make sure that the setup script only uses sysconfig and distutils. The os and sys modules of the build python are not (yet) overwritten.

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 https://launchpad.net/ubuntu/+source/zope.interface/4.0.3-0ubuntu2, 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.

PythonMultiArch