Re: Bug#974552: upgrade-reports: libc6/libcrypt split breaks perl during buster->bullseye upgrade
On Fri, Nov 20, 2020 at 09:30:23AM +0100, Aurelien Jarno wrote:
> 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.
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.
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.
> > 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.
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.)
> > 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.
It looks like perl-base 5.30.0-10 was the first version to acquire the
pre-dependency on libcrypt1.
--
Niko
Reply to: