[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: