There are maybe not many use cases where you do want to install an interpreter like python or perl for a foreign architecture, but there are some use case where such a setup makes sense. For now I see this limited for architecture pairs like amd64/i386, armel/armhf, ia64/i386, i.e. for architectures where the "foreign" interpreter can be run (without qemu). Use cases are
- running the OpenJDK hotspot JIT for i386 on ia64, an implementation which is much faster than the OpenJDK Zero interpreter on ia64. This can be done today in wheezy. The OpenJDK packages do use different prefixes and are co-installable. While the packages come with binaries, these are all installed using alternatives, so the packages can even be installed for more than architecture (no, I don't like this alternatives schema much). - running the IcedTea web plugin for i386 on amd64, because the downloaded binary code is only available for i386. This is currently possible in wheezy. - running a gdb:amd64 on i386 to debug 64bit binaries. This is the reason for our current gdb64 package on i386, but it is missing the support for the python based pretty printer. Installing gdb:amd64 on i386 in wheezy will remove the whole i386 python stack and then install the amd64 python stack. For this use case the needed amd64 python stuff should just be installed without removing the i386 packages. - install vim for a foreign architecture. Ok, not really a good use case, but it comes with an insane amount of embedded interpreters. It should be installable without removing the "native" interpreter packages, and the embedded interpreters should still be usable. - Third party modules for interpreters should be cross-buildable. Many build systems for interpreter languages are written in the interpreter language itself. So you do require the interpreter for the build, and the development files for the host. When trying to build a base system, you meet build dependencies on interpreters very early. You can either work around these by staged builds, or provide an interpreter which supports cross builds for third party packages. However most interpreters require some work to cross-build, and you have to figure out how to cross build the extensions. So the gdb/vim use cases would require co-installation of the runtime files for more than one architecture (including in most cases the shared library, some standard libraries, or subset of these), and keeping the interpreter for the default architecture. The cross build case would require in addition co-installed development packages, provided that these can be used for a cross-build. So what is the status for some runtimes/interpreters (would like to see some follow-up/corrections from package maintainers)? - OpenJDK: runtime and development files are co-installable, the package itself is not cross-buildable, and afaik nobody did try to cross build any bindings. - Perl: Afaik, Neil did prepare the interpreter to cross-build, and to co-install the runtime and development files. What about cross-building third party modules? - Python: co-installable runtime and development files, cross-buildability upstreamed for 2.7.4 and 3.3.1. There is a way to cross-build third party modules using distutils/setuptools. Packages are available in experimental, but because I didn't backport this to 2.6 and 3.2, not much useful. Install an Ubuntu raring (13.04) chroot to experiment with these. Details at http://wiki.debian.org/Python/MultiArch - Ruby: Afaik, not yet started on multiarch. - Tcl/Tk: Wookey and Dimitrij did start on that in Ubuntu, patches are available in Debian bug reports. Currently the shared libraries are split out into separate packages, and are co-installable. Not yet tested if this enough to run an embedded interpreter. - Lua, Ocaml, Haskell, Guile, ... ? Matthias -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/5170061f.9030...@debian.org
