Re: Multiarching perl
On Fri, Aug 10, 2012 at 05:14:15PM +0300, Niko Tyni wrote:
> I suppose I should do some experimenting based on all this.
Some results:
- the general concept seems to be working OK, and I've managed
to coinstall i386 and amd64 libperls and have them working
at the same time. (unsurprising, but still cool :)
- the concept where a newer perl would Break older libperl5.x
packages to limit co-installability doesn't work. More on that below.
- /usr/bin/a2p (of all things) needs special treatment: it's
the only arch dependent (compiled) binary outside perl-base.
Possibly we'd need a Multi-Arch: foreign perl-bin package just
for that :(
- the static i386 /usr/bin/perl is a problem: either we need
to link it dynamically, causing alleged performance problems due to
register starvation (AIUI), or we need to include both libperl and a
static perl in the Essential set, growing that by 1.6M (unpacked).
As discussed earlier in the thread, we have a problem if multiple
ABI versions of the perl interpreter are coinstallable because all the
XS modules need to match the perl ABI. OTOH, the coinstallability of
libperls is a requirement for /usr/bin/perl to work across upgrades.
My idea was to make the perl package Break older versions of libperl,
so that the libperl coinstallability would be limited to the upgrade
time. Unfortunately this doesn't seem to work. The older libperl would be
removed before perl-base was upgraded, briefly breaking /usr/bin/perl. My
best theory is that this happens because of conflicting requirements:
- old perl-base Pre-Depends: libperl5.14
-> upgrade perl-base before removing libperl5.14
- old perl Depends: old perl-base
-> upgrade perl before upgrading perl-base
- new perl Breaks: libperl5.14
-> remove libperl5.14 before upgrading perl
The cycle must be broken somewhere, and the pre-dependency is probably
equivalent to a regular dependency in this sense.
Whatever the reason, the pre-dependency got broken in my upgrade tests,
so that's a no-go.
The next best thing (possibly even better, or at least cleaner) I've
come up with is to make all the applications linking against libperl to
also depend on perlapi-*, just like XS module packages. This makes sure
that a perl-base upgrade will pull them along. The old libperl can still
stay on the system, but nothing should be linked against it so it doesn't
matter that it's ABI-incompatible with the XS modules on the system.
We could even make that part of the libperl shlibs, but that may
be a bit too intrusive. I'm not sure if all the applications embedding
Perl offer the user a way to execute arbitrary Perl code. Those that do
should depend on both perl and perlapi-* IMO, but any that don't might
be fine with just the embedded Perl interpreter and no standard library
at all.
Thoughts?
--
Niko Tyni ntyni@debian.org
Reply to: