Hi, On 2020-11-16 16:39, Niko Tyni wrote: > On Fri, Nov 13, 2020 at 08:48:19PM +0100, Sven Joachim wrote: > > On 2020-11-13 18:23 +0100, Niels Thykier wrote: > > > > > Control: reassign -1 perl-base > > > Control: affects -1 upgrade-reports > > > Control: severity -1 grave > > > > > > Hi Perl team, > > > > > > I have reassigned this bug to perl because perl-base being essential > > > must remain functional during an upgrade and AFAICT perl-base fails in > > > this case here. > > > > > > If it is a direct linkage, then you might be needing a Pre-Depends. If > > > it is an indirect linkage then I am not sure how to fix it. :-/ > > > > I don't think perl-base is doing anything wrong here, it already uses > > Pre-Depends. AFAICS the problem is that libcrypt.so.1 can temporarily > > go missing if libc6 2.31-4 is unpacked before libcrypt1, breaking the > > assumption that binaries from essential packages are always usable.
I don't understand what happened there. Sure there has been the perl transition, but the fact that perl depends on libcrypt1, it is the case for more than 6 months. > Indeed. As perl-base isn't upgraded yet at that point, there's nothing > we can do on that side. > > Apparently the new libc6 is still considered to satisfy the old perl-base > pre-dependency even when it (libc6) is only unpacked and its dependencies > are not yet satisfied. This seems similar to this paragraph from Debian > policy, section 7.2: > > When a package declaring a pre-dependency is about to be unpacked > the pre-dependency can be satisfied if the depended-on package > is either fully configured, or even if the depended-on package(s) > are only in the “Unpacked” or the “Half-Configured” state, > provided that they have been configured correctly at some point > in the past (and not removed or partially removed since). In this > case, both the previously-configured and currently “Unpacked” > or “Half-Configured” versions must satisfy any version clause > in the Pre-Depends field. > > The libc6 package has been configured correctly in the past, when > it still contained libcrypt1. > > As to the fix, I suspect we need a pre-dependency from libc6 to libcrypt1 > for one release cycle, so that libc6 cannot be unpacked before libcrypt1 > is fully installed. This has been tried, that works for upgrade, but then apt refuses to allow new installation of libc6+libxcrypt1, which makes it impossible to install foreign-arch versions on an existing system. > 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. This is something we can try indeed. Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
