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
