Perl embedding pain

[Ben Hutchings]

On Mon, 2014-08-25 at 16:20 -0700, Niko Tyni wrote:
> 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.

Sure, that might be useful to some but it's not something I immediately
care about.

> 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?

Installable and working, yes.

> 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,

Yes, I had a look around the current perl binary packages and was
surprised to find how many packages the modules are spread across!

> 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.

At the archive level, they would still all be part of a single testing
transition.  But on any Debian system, they wouldn't need to be upgraded
at the same time whereas they do now.

> 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?

I don't believe it does.  But as other packages might, this implies that
the other XS module packages would need to change name too.  That seems
like it would require an annoying amount of work.

Ben.

-- 
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/perl-maintainers/attachments/20140826/548a9558/attachment.sig>