Perl embedding pain

[Niko Tyni]

On Thu, Aug 21, 2014 at 01:07:16PM -0700, Ben Hutchings wrote:
> As libperl5.* packages currently depend on an exact version of
> perl-base, coinstallation of multiple library versions is impossible.
> Transitions are not only a pain for developers, but users must upgrade
> all Perl extensions and embedding applications at the same time as the
> perl package.
> 
> Why don't all the Perl package names include the ABI version, leaving
> perl as a metapackage?
> 
> With linux-tools-* packages, this is particularly problematic as the
> older packages will never be rebuilt for the new Perl version.  My
> inclination is to 'fix' this by removing Perl integration from perf.
> Please let us know whether it will be possible to fix this properly.

Hi,

while I wasn't around when the current implementation was designed,
I believe it was largely due to extremely bad experiences with multiple
coinstallable perl versions around perl-5.6 times (ca. 2000). I'm cc'ing
Brendan O'Dea in case he has horror stories or advice to share. (I'm
also cc'ing perl at packages.debian.org as a slightly more transparent
contact for this.)

For my part, I'm sort of interested in leaving old libperl versions
installable after upgrades, but I wouldn't want to be supporting
/usr/bin/perl5.18 and /usr/bin/perl5.20 simultaneously or even having
separate source packages for different Perl versions in the archive at the
same time.  Backward compatibility is a high priority for Perl upstream,
and I don't think the (generally low) level of breakage when upgrading
between Perl major versions justifies the cost of maintaining several
versions in the archive.

My understanding of your use case is that just leaving old libperl
versions installable would meet your primary concerns?

Within the scope of that, I have two main considerations for the
implementation:

1) the robustness of perl-base: it's Essential:yes so we guarantee that
   /usr/bin/perl and the modules in perl-base won't break during upgrades.

An embedded libperl needs at a minimum the full standard library to be
properly usable. Parts of this are currently in the perl-base package
and considered part of the Essential functionality, so if we split them
out we need to be careful with pre-dependencies etc. to keep it working.
I don't think this is a blocker.

2) there's 500ish extension packages ("XS modules") in the archive that
   need to be taken into account.

As you noted, these currently need to be upgraded in the same go. That
is not going to change without fully supporting multiple perl versions
and compiling the extensions for all of them like the Python world
does. How big a problem is this really? The gains don't seem worth the
added complexity from my point of view.

I'm not sure how usable the old embedded interpreter is going to be
without those XS module packages. I suppose they can always be installed
from CPAN into /usr/local, so perhaps this is acceptable. Looking at the
linux-tools-* dependencies, I assume that particular use case doesn't
require other XS module packages?
-- 
Niko Tyni   ntyni at debian.org