On 2021-03-19 15:24, Ivo De Decker wrote: > Hi, > > On Fri, Nov 20, 2020 at 01:44:50PM +0100, Alois Wohlschlager wrote: > > Am Freitag, den 20.11.2020, 09:13 +0000 schrieb Niko Tyni: > > > I don't think this is related to the recent perl 5.30 -> 5.32 > > > transition. > > > The report is about a buster -> bullseye upgrade, and perl in > > > bullseye > > > was still at 5.30 at the time. > > > > > > In any case, the report says perl (presumably perl-base as well) was > > > still at the buster version when the breakage happened, so it didn't > > > have the libcrypt1 dependency. > > > > This is indeed the case. perl-base was only upgraded to the bullseye > > version after I manually fixed the breakage. (Indeed, when I wrote > > "Perl" I actually meant "perl-base", but perl itself was also at the > > buster version FWIW.) > > > > > FWIW the breakage can be reproduced just by manually unpacking the > > > new > > > libc6 on a buster system. > > > > > > I don't know why it hasn't been encountered earlier. > > > > I found out by now that the problem actually has been encountered > > earlier(#946599, where it broke libc's maintainer scripts). In my case, > > it broke the check-support-status hook providd by debian-security- > > support. (I'm not sure whether it's such a great idea for dpkg to run > > hooks when dependencies are broken, but that's what was happening on my > > system.) > > I filed #984539 against debian-security-support, to make sure the hook never > fails. That doesn't fix this bug, but at least it might reduce the potential > impact of issues like these. > > > > Yeah, I missed the libcrypt1 -> libc6 dependency. That prevents this > > > option. (I wonder if the circular dependency is a factor in apt > > > choosing > > > the upgrade order that results in this breakage.) > > > > I'm not sure what's going on here, as libcrypt1's libc6 Depends should > > be satisfied by the buster version. So it seems to me like installing > > libcrypt1 before upgrading libc6 should be strictly better than doing > > it the other way round, even purely in terms of satisfaction of > > dependencies. > > > > Maybe it's worth investigating why apt decides to proceed the "wrong" > > way anyway, should I try setting up a VM to reproduce the problem? > > I did some upgrade tests starting from the > debian-10-generic-amd64-20210208-542.qcow2 cloud image, and in all my tests, > apt chooses to unpack libc6 before libcrypt1. > > 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. > Note that even if the hook isn't run or doesn't fail, there is still a period > between the unpack of libc6 and libcrypt1 where perl is broken. If other > operations are done in between that cause maintainer scripts to run, these > could potentially call perl, which will be broken in this case. > > > > > > Another option might be to have the new libc6 Conflict with old > > > > > versions > > > > > of Essential:yes packages that need libcrypt1, forcing those > > > > > Essential:yes > > > > > packages to get upgraded first. A quick check based on libcrypt1 > > > > > reverse > > > > > dependencies in sid shows perl-base, login and util-linux. I'm > > > > > not sure > > > > > if this list is exhaustive, though. > > > > Having libc6 Conflict with one of those packages should be enough, > > right? > > I tried creating libc6 packages with either a conflits or a breaks agains the > old perl-base or the old login, and in each case I get this error: > > E: This installation run will require temporarily removing the essential > package libc6:amd64 due to a Conflicts/Pre-Depends loop. This is often bad, > but if you really want to do it, activate the APT::Force-LoopBreak option. > E: Internal Error, Could not early remove libc6:amd64 (2) > > So it doesn't look like this will work. I haven't tried, but it's what I was expecting. > 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. > 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 The problem of removing the break, is that we loose the possibility of downgrades. Is it something acceptable? > 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? Cheers, Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net