Bug#962138: perl-base: libperl5.30 version skew can break essential functionality

[Dominic Hargreaves]

On Wed, Jun 03, 2020 at 07:39:38PM +0300, Niko Tyni wrote:
> Package: perl-base
> Version: 5.30.2-1
> Severity: serious
> 
> Our Perl package dependencies and search path arrangements allow
> for a suitably versioned libperl5.30 package to break perl-base
> functionality. This is bad as perl-base is Essential:yes and is therefore
> required to stay functional at all times.
> 
> The specific version skew that triggers this is between minor upstream
> versions, so for instance 5.30.2-1 -> 5.30.3-1, which are the current
> version in testing and unstable.

> Minor upstream version upgrades in testing/unstable have been relatively
> rare in the past, and oldstable -> stable upgrades have always
> incorporated a major version bump since the 5.10 times (squeeze), when
> the dependencies and the package set were very different.

> I'm afraid this also means that a minor upstream version upgrade
> in stable has a higher risk of breaking things, so maybe we should
> reconsider #961443.

Agreed.
 
> I see two ways of fixing this (but happy to entertain other suggestions too).
> 
> A) Move /usr/lib/<triplet>/perl-base up on the @INC search path. This is
>    shipped in perl-base and includes the parts of the standard library
>    we consider part of Essential:yes functionality. It's currently last
>    on @INC. The libperl5.30 and perl-modules-5.30 packages include copies
>    of these files, shipped in /usr/{lib,share}/<triplet>/perl/5.30,
>    so that they can be used "standalone" for different architectures or
>    major versions. The position of these copies higher on @INC makes this
>    bug possible.
> 
>    IIRC I put /usr/lib/<triplet>/perl-base last because it's a nonstandard
>    divergence from the upstream way of doing things, and I wanted it not
>    to have an effect in the "normal" case when all the related packages
>    are installed and configured. So it was only supposed to be a safeguard
>    during upgrades and such. Clearly the safeguard is incomplete.
> 
> B) Do away with the /usr/{share,lib/x86_64-linux-gnu}/perl/5.30 -> 5.30.x
>    symlinks currently shipped in libperl5.30 and perl-modules-5.30,
>    and have the perl search path include the full upstream version. We
>    tried this with the multiarch changes in 5.22 but reverted it with
>    #787158 .  As I noted in that bug, this would mean that long running
>    Perl programs could have @INC changed underneath them during version
>    upgrades. This is not a showstopper by any means; we already have the
>    'perl-major-upgrade' trigger for similar situations during major
>    version upgrades, with at least some buy-in from packages like
>    spamassassin IIRC.
> 
> I think A) is currently my preferred way of fixing this, and I think
> the upstream "divergence" issue it creates is not very important. I
> can envision some corner case regressions where standard library
> modules expect other modules to be in the same directory, but those
> seem improbable.
> 
> The main reason why I prefer option A is that it seems conceptually more
> correct (improving the standalone properties of perl-base). Also, option
> B may be harder to implement while keeping upgrade paths robust. But I
> haven't really thought this through yet.

Agreed, the upstream divergence seems like a very minor thing compared
to the advantage of a simpler, more predictable fix.

> On a brighter note, either of these options would close #798626 :)
> 
> Apologies for my verbosity and thanks for reading through; ideas and
> comments are naturally welcome. Despite the severity I don't think this
> is particularly urgent, except with the possibly implications for stable
> updates / #961443.

One reason to make this urgent is so that this issue doesn't occur when
5.30.3-1 transitions to testing in a couple of days. It doesn't sound
like the fix is especially hard, so it might be worth pushing through
if we can?

Cheers
Dominic