On Wed, Apr 14, 2021 at 08:50:46PM +0200, Paul Gevers wrote:
> Hi Ivo, Marco,
>
> On 06-04-2021 22:10, Ivo De Decker wrote:
> > I ran a number of (partial and full) upgrade tests, and they all seem to
> > work
> > fine. In all cases, libcrypt1 is installed before libc6, and there is no
> > intermediate situations where libcrypt.so.1 is missing.
>
> The patch looks sensible after reading the discussion in these bugs. Can
> we have an upload soon to have exposure?
Hi, thanks for your work on this and sorry I'm chiming in so late.
I'm concerned that AFAICS no change in src:libxcrypt can make sure that
the new libc6 is never unpacked before libcrypt1.
(buster-amd64)# dpkg --unpack libc6_2.31-11_amd64.deb
(Reading database ... 12224 files and directories currently installed.)
Preparing to unpack libc6_2.31-11_amd64.deb ...
debconf: unable to initialize frontend: Dialog
debconf: (No usable dialog-like program is installed, so the dialog based
frontend cannot be used. at /usr/share/perl5/Debconf/FrontEnd/Dialog.pm line
76.)
debconf: falling back to frontend: Readline
Unpacking libc6:amd64 (2.31-11) over (2.28-10) ...
(buster-amd64)# perl
perl: error while loading shared libraries: libcrypt.so.1: cannot open shared
object file: No such file or directory
It may well be enough to make this improbable enough in practice. Ivo's
testing certainly seems to indicate so. It still makes me a bit uneasy.
I'm happy to be proved wrong of course. Do the Important or Protected
fields in the patch affect apt's behaviour in this, for instance?
The solution Aurelien mentioned of copying the old libcrypt in
libc6.preinst and cleaning up in libc6.postinst would eliminate this
failure mode totally. But I can see it's not very desirable and may be
hard to make robust.
Just wanted to bring this up explicitly. Not objecting if we deem the
risk of remaining corner case issues small enough that it's worth taking.
--
Niko
