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.
[...] > 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. We did this for 5.30.3-2, moving /usr/lib/<triplet>/perl-base almost to the top (right after /etc/perl). This caused a regression in the libscalar-list-utils-perl package, because the older versions of the Scalar-List-Utils modules in perl-base now take priority. So dual life modules in perl-base can no longer be overridden by a separate package with the current @INC ordering. I think we need to move the perl-base between vendor and core, so after /usr/lib/x86_64-linux-gnu/perl/5.30 but before /usr/share/perl/5.30. > 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. Unfortunately one of these corner causes is rather prominent: ExtUtils::MakeMaker checks that the Config.pm it has loaded is on archlibexp (currently /usr/lib/<triplet>/perl/5.30), which is directly contrary to our purposes here. The check is only a warning, but it shows on every architecture specific build. I'm not currently aware of any build failures or the like caused by it. Nevertheless, I think we should patch the check to allow for the perl-base specific path. One more thing I've spotted in the 5.30.3-2 britney autopkgtest tests is a regression in libextutils-hascompiler-perl. I think that needs to be fixed in libextutils-hascompiler-perl and I'll file a separate bug about it. -- Niko Tyni nt...@debian.org