On Fri, May 02, 2014 at 05:14:48PM +0300, Niko Tyni wrote:
> It seems to me that an interpreter supporting DSO language extensions
> can have multi-arch support at several different levels.
> 1) multiarch annotations for /usr/bin/interp, but no Multi-Arch:same
> packages. The architecture of /usr/bin/interp must match the
> architecture of any corresponding embedded interpreter packages
> 2) Multi-Arch:same embedded interpreter packages (with the standard
> library), but separately packaged DSO extensions can be installed
> for only one architecture at a time
> 3) Multi-Arch:same embedded interpreters (+stdlib), but packaged DSO
> extensions aren't limited to one architecture
> I think python3 is doing 2), and ruby2.0 seems to be trying to do 3).
> I'm currently contemplating whether to do 1) or 2) for perl. I'll
> follow up on that in a separate mail.
OK, as I see it, the difference in packaging complexity between 1) and 2)
for perl is substantial (two new binary packages to make the standard
library Multi-Arch:same, requires splitting the Essential:yes perl-base
package). I'm not sure if the benefits of 2) are worth it as long as 3)
is not attainable.
1) would mean that packages just using #!/usr/bin/perl could be installed
on non-native architectures (possibly after a transition period adding
:any qualifiers to the "perl" dependencies), at least as long as they
don't depend on any DSO extension packages ("XS modules" in Perl-speak).
Pure perl (Architecture:all) module packages would be installable on
non-native architectures after a transition period marking them as
Multi-Arch:foreign (necessary as long as we treat Architecture:all
packages as being of the native architecture.)
2) would add the packages linking against libperl (currently numbering 68)
to the mix. However, while those package would become installable on
non-native architectures, the corresponding embedded interpreters in would
be severely limited by the unavailability of packaged DSO extensions.
I've given up hope for 3) in the near future.
I can see that 2) is a necessary step towards 3) when our infrastructure
has improved, but I think I'd rather postpone the added complexity until
it's really worth it. Also, 2) does open up the possibility for similar
problems as 3) if somebody inadvertently makes a DSO extension package
Multi-Arch:foreign.
So I'm currently inclined to settle with 1) and just add multiarch
annotations to perl (and perl-modules) for jessie, leaving perl-base and
libperl5.18 alone. However, I'm certainly willing to listen to arguments
for 2), or any other thoughts on this subject.
--
Niko Tyni nt...@debian.org
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140503065730.GA5919@estella.local.invalid
