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