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

[Niko Tyni]

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   ntyni at debian.org