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.
>
> Thoughts?
Hi Niko,
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[1], and making explicit the
exact requirements of each package will be helpful anyway.
[1] 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)
Reply to: