Perl embedding pain

[Brendan O'Dea]

On 26 August 2014 09:20, Niko Tyni <ntyni at debian.org> 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.
>
> 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.)

The current Perl policy was optimised for reducing the need to rebuild
modules every time a new Perl version is released.  There are many
packaged modules, and it requires a lot of coordination to get them
all ready for a new incompatible Perl release.  The goal was to allow
modules to continue working across minor releases where possible to
reduce this work.

Packages embedding Perl should get much of the same benefit as Perl
modules: persistence across compatible Perl versions (as defined by
perlapi-*), with the additional requirement that long-running
processes may need to hook into the _perl-major-upgrade_ trigger .

There was another issue at the time (the horror stories which Niko
alludes to) where /usr/bin/perl was managed by update-alternatives,
which is written in Perl, which led (as you may be able to guess) to
all measure of hilarity* at the time, with many instances of upgrades
breaking the /usr/bin/perl link into /etc/alternatives and
consequently the mechanism for fixing that breakage.  This is the
reason why there is only one perl-base package, and that it works even
when unconfigured.

--bod

* https://lists.debian.org/debian-perl/2001/01/msg00005.html