Your message dated Thu, 04 Jun 2020 23:34:00 +0000
with message-id <e1jgzn2-000coq...@fasolo.debian.org>
and subject line Bug#962138: fixed in perl 5.30.3-2
has caused the Debian Bug report #962138,
regarding perl-base: libperl5.30 version skew can break essential functionality
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
962138: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962138
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
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
--- End Message ---
--- Begin Message ---
Source: perl
Source-Version: 5.30.3-2
Done: Dominic Hargreaves <d...@earth.li>
We believe that the bug you reported is fixed in the latest version of
perl, which is due to be installed in the Debian FTP archive.
A summary of the changes between this version and the previous one is
attached.
Thank you for reporting the bug, which will now be closed. If you
have further comments please address them to 962...@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.
Debian distribution maintenance software
pp.
Dominic Hargreaves <d...@earth.li> (supplier of updated perl package)
(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmas...@ftp-master.debian.org)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Format: 1.8
Date: Fri, 05 Jun 2020 00:21:01 +0100
Source: perl
Architecture: source
Version: 5.30.3-2
Distribution: unstable
Urgency: medium
Maintainer: Niko Tyni <nt...@debian.org>
Changed-By: Dominic Hargreaves <d...@earth.li>
Closes: 961928 962019 962138
Changes:
perl (5.30.3-2) unstable; urgency=medium
.
[ Niko Tyni ]
* Fix version parsing logic in a maintainer test.
* Move perl-base specific library up on @INC. This eliminates the
chance of incompatible libperl5.xx modules overriding the perl-base
ones during upgrades and the like. (Closes: #962138)
.
[ Dominic Hargreaves ]
* Remove lingering references to old deprecated modules (Closes: #961928)
* Fix FTBFS with IPv6-only host (Closes: #962019)
Checksums-Sha1:
04d280daa18aba74aac85b6c2aaf6413a5c2f1f4 2868 perl_5.30.3-2.dsc
41249f7a57a5f3b8125bd913c28f860ccfcf26a8 168796 perl_5.30.3-2.debian.tar.xz
b89002877ca7201819ebf10ec081369d097668ed 5903 perl_5.30.3-2_source.buildinfo
Checksums-Sha256:
ca6ead446373fc9883039a47db73c30b388dc4915eace71824f005bd106d5b75 2868
perl_5.30.3-2.dsc
099d7356599abac86d9fb0f0182fb80601691f679a1c165f20dc729a76fdac2e 168796
perl_5.30.3-2.debian.tar.xz
34fcf99e71b6ad905b0054b1f9e7a58bb68bd1fb99894077418ea377350489a6 5903
perl_5.30.3-2_source.buildinfo
Files:
6e8b5ab1bd3ec1c96d7ffc32877d69d4 2868 perl standard perl_5.30.3-2.dsc
9c0274a203867bfd59c1676cccd323f7 168796 perl standard
perl_5.30.3-2.debian.tar.xz
fbbc9039e95bda507bf477b169bd73df 5903 perl standard
perl_5.30.3-2_source.buildinfo
-----BEGIN PGP SIGNATURE-----
iQJBBAEBCAArFiEEy0llJ/kAnyscGnbawAV+cU1pT7IFAl7Zgj8NHGRvbUBlYXJ0
aC5saQAKCRDABX5xTWlPslQ7EACz8JQkYavgVUueJChc2AgNT87M7aiSAfP7IrD6
Rk+NFWYewM5KFiCPCX/bg7rZ9iU4gi9LbS8cx50uNE/LAlUn2UmX4M+dY336o3Jr
VTD7Ue69gxMnHgcRUjz6hPrzQxtjS3pzKnxdg5OzxVqfRBFmIEy2yddGZyX+zgwy
Ns0xouxJ7+eFx05kXWRoJm2myUs4qhtUof/KRfRT8P1gf/Evfj6MLV8fJxqXS3zS
7TCXfSxII/SXtM8utmGDMIlhu0mWoMNVStfO5HzQ836UN08VMA9GvRglARIB+6VM
6KLUfXMv5iRbFQBaVPOLkCU/87jGwmTjim+lNI4UaXEeH0GxdPP9QDp2OGzkTOzt
3a49USJioYyCOKe8qx5+WjeC4OY9Cg3A7gIeiJ8wqWzIaymJSQUK7vxbJjKaqMB9
YsKjsGH1czLXnifWHm9URC4VQCQeLsXYJW10FeUlZGqcfsyUFDM44s09GYlVC+Hv
zAz2I6vr7xVGo+w9rYCh9y6zbvla+ev92fgq4a6ZhnQhNQv64T9UAkjndBFP7k9R
PRB9Ug1ZR0XuigbsitRLSTfdjW0vY686tz6FgrQQLGbl6Gtkm6G0ooNE0sCCNvn5
/Jb2m4kYQko/o9MnOb/COa8kSiiAz02Hx1EqyMtG+FIti22jrw4fupFFcyGdQ9L/
QzN/4g==
=OGxv
-----END PGP SIGNATURE-----
--- End Message ---
