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
