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.
The transcript at the end, from a current bullseye chroot with perl-base
and libperl5.30 but no perl installed, shows how perl-base can be
upgraded from sid without touching the other packages. After this, the
standard library in libperl5.30 is different version from perl-base but
has preference on the search path, causing version check bailouts and
breaking perl-base.
This works in the other direction too: if a newer version of libperl5.30
is unpacked, perl-base stops working in the same way. However,
the versioned dependency chain libperl5.30 -> perl-modules-5.30 (>=
${source:Version}) -> perl-base (>= ${Upstream-Version}-1) means that
libperl5.30 can't be configured in this combination.
The initial FTBFS of 5.30.3-1 on an arch:all sid buildd briefly resulted
in ideal conditions for this bug to trigger: unstable/amd64 then had
perl-modules-5.30 at version 5.30.2-1, but libperl5.30 and perl-base
at 5.30.3-1. Systems without the perl binary package were at that point
prone to upgrade to the newer perl-base while keeping perl-modules-5.30
and libperl5.30 at the old version. The autopkgtest checks of hkgerman
hit this when /usr/sbin/update-dictcommon-aspell (in dictionaries-common)
broke.
https://ci.debian.net/data/autopkgtest/testing/arm64/h/hkgerman/5736806/log.gz
It's not clear to me what the practical effects of this issue are.
Pretty much all real systems have the perl binary package installed,
which seems to make apt unpack libperl5.30 and perl-base very close to
each other. We haven't had any upgrade failure reports from the recent
5.30.0 -> 5.30.1 upgrade FWIW.
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.
In any case, I think this needs to be fixed and should probably be
considered release critical.
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.
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.
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.
------------------------------------------------------------
Transcript:
# dpkg -l perl-base libperl5.30 perl perl-modules-5.30
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Architecture Description
+++-=================-============-============-=====================================================
ii libperl5.30:amd64 5.30.2-1 amd64 shared Perl library
rc perl 5.30.2-1 amd64 Larry Wall's Practical
Extraction and Report Language
ii perl-base 5.30.2-1 amd64 minimal Perl system
ii perl-modules-5.30 5.30.2-1 all Core Perl modules
# sed -i s/bullseye/sid/ /etc/apt/sources.list
# apt update
[...]
# apt install perl-base
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
perl sensible-utils
The following packages will be upgraded:
perl-base
1 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.
Need to get 1576 kB of archives.
After this operation, 9216 B of additional disk space will be used.
Get:1 http://localhost:3142/debian sid/main amd64 perl-base amd64 5.30.3-1
[1576 kB]
Fetched 1576 kB in 0s (93.2 MB/s)
debconf: delaying package configuration, since apt-utils is not installed
(Reading database ... 11935 files and directories currently installed.)
Preparing to unpack .../perl-base_5.30.3-1_amd64.deb ...
Unpacking perl-base (5.30.3-1) over (5.30.2-1) ...
Setting up perl-base (5.30.3-1) ...
# perl -V
/dev/null: Perl lib version (5.30.2) doesn't match executable '/usr/bin/perl'
version (5.30.3) at /usr/lib/x86_64-linux-gnu/perl/5.30/Config.pm line 62.
Compilation failed in require.
BEGIN failed--compilation aborted.
--
Niko Tyni nt...@debian.org
