Re: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade

[Aurelien Jarno <aurelien@aurel32.net>]

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
aurelien@aurel32.net                 http://www.aurel32.net