Hi, On Fri, Mar 19, 2021 at 03:51:34PM +0100, Aurelien Jarno wrote: > > However, in all of my tests, between the unpack of the new libc6 and > > libcrypt1 > > only other unpacks where done, and no dpkg hooks where run. If you have a > > way > > to reproduce the upgrade where dpkg ran the hook in between, that might be > > interesting. Do you still have a list of packages that was installed before > > you started the upgrade? > > Have you tried to install a foreign libc6? It usually makes the upgrade > a bit more tricky and could be what triggers the issue.
I installed whois:i386, which pulled in libc6:i386 as well. Feel free to suggest a larger set of i386 for me to try. > > Note that I manually changed the binaries and didn't rebuild glibc, so I > > might > > have made a mistake, but this scenario should certainly be tested before > > something like this is uploaded to unstable. Maybe an upload to experimental > > might allow people to test this more easily? > > > > I Cced the apt maintainers to see if they have other suggestions to get > > apt/dpkg to unpack libcrypt1 before libc6. > > Another (ugly) suggestions we discussed at some point was: > 1) in the preinst copy the existing libcrypt1 library to a private and > add it to ldconfig with lower priority than /usr/lib/$(MULTIARCH) > 2) in the postinst remove these copy and ldconfig configuration. Do you think this is something that you can get to work in a reliable way? > > I wonder if all this might be caused by the breaks from libcrypt1 (against > > libc6 (<< 2.29-4)). Is there a way to remove the breaks without causing > > issues? Maybe this is somewhat similar to the situation in I tried this with a modified libcrypt1 binary (removing the breaks), and it fails (/lib/x86_64-linux-gnu/libcrypt.so.1 is missing after the libc6 unpack). I guess that's because of #953562: libc6 shipped /lib/x86_64-linux-gnu/libcrypt.so.1 while libcrypt1 ships /usr/lib/x86_64-linux-gnu/libcrypt.so.1 Obviously, for dpkg these are 2 different files, but on a system with merged /usr they are not. > The problem of removing the break, is that we loose the possibility of > downgrades. Is it something acceptable? Well, I guess if that is the cost of not breaking people's systems on upgrade, that sounds like an acceptable trade-off. But I might be overlooking certain scenarios. > > https://bugs.debian.org/972936#24: libgcc-s1 takes over binaries from > > libgcc1, > > but only 'replaces' it, without breaks (note that extra steps had to be > > taken > > to avoid further issues (adding Important: yes and Protected: yes)). > > Are this extra-steps basically required to prevent downgrades? They are required to prevent you from removing libcrypt1 again: on a buster system, install such a hypothetical libcrypt1 from bullseye (which takes over libcrypt.so.1). Then remove that again. Now libcrypt.so.1 is missing. If the breaks is present, libcrypt1 can only be installed together with the new libc6, which prevents you from removing libcrypt1 afterwards. Cheers, Ivo
