Your message dated Thu, 04 Jun 2020 23:34:00 +0000 with message-id <[email protected]> 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 [email protected] immediately.) -- 962138: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962138 Debian Bug Tracking System Contact [email protected] 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 [email protected]
--- End Message ---
--- Begin Message ---Source: perl Source-Version: 5.30.3-2 Done: Dominic Hargreaves <[email protected]> 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 [email protected], and the maintainer will reopen the bug report if appropriate. Debian distribution maintenance software pp. Dominic Hargreaves <[email protected]> (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 [email protected]) -----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 <[email protected]> Changed-By: Dominic Hargreaves <[email protected]> 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 ---
