Hi! [ I had pending warning about this on debian-devel before the release, so this is a good way to do that. :) ]
On Thu, 2013-04-18 at 16:41:35 +0200, Matthias Klose wrote: > 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 I agree this would be desirable, but unfortunately I don't think it's currently possible (w/o compromising the dependency system). > So what is the status for some runtimes/interpreters (would like to see some > follow-up/corrections from package maintainers)? > - 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 As I pointed out on the debian-perl mailing list, after having discussed about multiarch support for perl, I don't think a fully multiarchified perl (nor at least python) should be uploaded to sid, as going full multiarch on the combination of a program frontend to an interpreter in shared library form, plus architecture dependent modules makes for situations that can bypass the dependency system and get into broken installations. Please see [0] for more details, although the "solution" I proposed is bogus and would not solve much as that does not help with arch-dep modules being depended by arch-indep ones and being run through the shared library interpreter, because the dependency to match is against the running interpreter, not just the program one. [0] <https://lists.debian.org/debian-perl/2012/12/msg00000.html> I've not checked the situation with other interpreters, but if they are similar to perl/python then doing full-multiarch might be a bad idea too for those. I think the full-multiarch support for python in experimental should really be reverted. Thanks, Guillem -- 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/20130418223307.ga12...@gaara.hadrons.org