Re: Multiarching perl
On Wed, Nov 21, 2012 at 12:06:10AM +0100, Guillem Jover wrote:
> OOC what would be the point of making perl co-installable with itself
> when perl-base will not be? The .so files in perl will not be usable
> for example w/o the matching perl-base:arch.
[...]
> and the XS module is arch:bar, and it simply Depends (w/o being
> loosened with an :any arch-qualifier) on the /usr/bin/perl package,
OK, this seems to be where we aren't on the same page. I think the
.so files in the perl package and the XS module packages can be usable
without matching the architecture of /usr/bin/perl, as long as they match
an installed libperl. Therefore XS module packages shouldn't Depend on
the /usr/bin/perl package at all, only on the libperl one (probably via
a virtual package like perlapi-5.14-amd64 or something like that).
Applications generally link against libperl because they embed a Perl
interpreter and let the user run arbitrary programs on that. Offering a
Perl interpreter without the standard library is not acceptable at
all IMO. So if we make libperl5.xx co-installable with itself (which
I understand to be the whole point of "multiarching perl"), we need to
make the standard library co-installable with itself too.
I also think we should strive to make the whole XS module stack packaged
in Debian available to non-native arch embedded Perl interpreters,
which means making them co-installable with themselves too.
My current experimental implementation of a new perl package split that
tries to solve this puzzle is:
- perl-base contains only /usr/bin/perl, Pre-Depends on libperl5.xx,
M-A: allowed based on the earlier discussion (but M-A: foreign also
seems like an option?)
- libperl5.xx (M-A:same) contains libperl.so.5.14 and the part of the
standard library currently in perl-base
- perl (M-A:same or M-A:allowed?) contains the rest of the standard
library (possibly keeping the split into arch:all perl-modules, but
they could be merged if necessary.)
I was thinking libperl5.14/amd64 would Provide: perlapi-5.14-amd64
or something like that, and XS module packages would Depend on that.
This guarantees there is a libperl on the system that can use the XS
module, but not necessarily that /usr/bin/perl can use it.
Many Perl scripts and most XS modules would need to Depend on perl because
they use those parts of the standard library. This seems to indicate that
it's the perl package that would have the dual nature and be M-A:allowed?
Does this make sense, or am I overengineering all this?
In case it does make sense, how should the dependencies read for
a devscripts-like arch:any package that needs an XS module (say
libnet-ssleay-perl) for a /usr/bin/perl script?
--
Niko Tyni ntyni@debian.org
Reply to: