Bug#979970: libselinux1: dependency to newer libc6 ignored by/missing for aptitude

[Julian Andres Klode <jak@debian.org>]

On Tue, Jan 26, 2021 at 12:52:52PM +0100, Aurelien Jarno wrote:
> reassign 979970 src:glibc,src:libselinux,src:apt,src:openssh
> thanks
> 
> On 2021-01-25 11:59, Laurent Bigonville wrote:
> > reassign 979970 src:glibc 2.30-1
> > affects 979970 + libselinux1
> > thanks
> > 
> > On Tue, 12 Jan 2021 13:31:19 +0100 Charlemagne Lasse
> > <charlemagnelasse@gmail.com> wrote:
> > 
> > > Right now, an update from buster to bullseye on amd64 completely
> > > bricks the system because libselinux1 is requiring a libc6 which is
> > > not yet installed on the system:
> > >
> > > Preparing to unpack .../0-libselinux1_3.1-2+b2_amd64.deb ...
> > > De-configuring libselinux1:i386 (2.8-1+b1) ...
> > > Unpacking libselinux1:amd64 (3.1-2+b2) over (2.8-1+b1) ...
> > > tar: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.30' not
> > > found (required by /lib/x86_64-linux-gnu/libselinux.so.1)
> > > dpkg-deb: error: tar subprocess returned error exit status 1
> > >
> > > It is then not possible anymore to recover the system because dpkg
> > > (mv, ...) is no longer working.
> > >
> > > There is most likely some kind dependency missing to let aptitude
> > > known that it must first update libc6 before it can update
> > > libselinux1. At least on this system, the installed version of libc6
> > > for amd64 and i386 was still 2.28-10 when this happened
> > 
> > After some discussion on IRC it looks like the problem is apparently coming
> > from the breaks added to the libc6 package.
> 
> The break hasn't been added randomly, but in response to upstream
> release notes and bug #965932. In short the openssh seccomp filters in
> buster are too narrow, and do not allow the new 64-bit syscalls needed
> for 64-bit time_t compatibility to be used.
> 
> So we definitely can't drop this break. For me this is not a libc6 bug.
> Or if it is, it is as much the fault of libc6 (for using new syscalls)
> than libselinux1 (for starting using symbol versioning).

This is not a question of finding the right solution, but more of the
least worst one.

Currently, the breaks potentially avoids non-working openssh-server
during a partial upgrade at the expense of breaking the system in a full
upgrade. We can't have that.

The reason this happens is the cycle: New libselinux1 needs new libc6,
new libc6 needs newer libselinux1.

The right solution would be to deconfigure libselinux1, then unpack
libc6, then unpack new libselinux1, but it seems that this is not what's
happening, and we can't easily change apt to fix it.

An alternative solution, for openssh-server would be to avoid using the
new syscalls for 64-bit time_t compatibility I assume (forcing it to
link with older symbol versions?), but there are other cycles between
libselinux1 and libc6 from what I heard. So well, like hack up libc6 to
avoid exposing the new symbol versions and recompile everything against
it?

If you have alternative suggestions to avoid removing the Breaks, please
let me know, but as it stands, I believe that this is the option that
causes the least amount of breakage.

We've reached the point where we have too many dependencies and
conflicts too low in the stack, and it becomes too much for apt to
handle.
-- 
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer                              i speak de, en