Re: Multiarching perl
On Sat, Sep 01, 2012 at 09:11:18AM +0300, Niko Tyni wrote:
> 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.
Thanks for looking at this! To the extent I have been able to follow
along with the details, this all sounds fine. Growing Essential by 1.6MB
doesn't *sound* excessive to me.
Requiring sourceful uploads to packages depending on libperl isn't ideal,
but the number of those is reasonably small, and making explicit the
exact requirements of each package will be helpful anyway.
 there are 45 packages in sid depending on libperl-* which don't
already depend on perlapi-*.
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)