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.
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.
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.
The first option looks less intrusive to me.
Disclaimer: I haven't tested any of this :)
--
Niko Tyni nt...@debian.org
