Re: multiarch and interpreters/runtimes
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
Reply to: