Bug#882255: libc6-amd64: Multilib causes catastrophic system failure during upgrade to libc 2.25
On Mon, 20 Nov 2017, Samuel Thibault wrote:
> Mikulas Patocka, on lun. 20 nov. 2017 19:13:31 +0100, wrote:
> > There is package libc6-amd64:i386 and libc6-amd64:x32 (which provide
> > x86-64 libc in /lib64/). This package is not technically needed (because
> > x86-64 libc is already installed in /lib/x86_64-linux-gnu/), but it is
> > installed nonetheless because of some dependencies.
>
> The issue of libc6-amd64:i386 conflicting with libc6:amd64 is not new, I
> tried to do it in the past, just to see, with the same kind of effect as
> you had.
>
> The question is rather how that got pulled at all. What package thinks
> it's a good idea to pull libc6-amd64? Apart from libc64* packages
> (which should normally not get pulled either), I can see uc-echo which
> should rather use foreign dependencies, and :i386 multilib packages
> which don't really make sense to install either.
>
> I don't remember whether it was tried to make libc6-amd64:i386 conflict
> with libc6:amd64 (and vice-versa for i386) to make sure that this
> doesn't happen by misfortune?
>
> Samuel
libc6-amd64 is pulled by lib64asan0, lib64asan1, lib64asan2, lib64asan3,
lib64asan4, lib64atomic1, lib64cilkrts5, lib64gcc1, lib64gomp1, lib64itm1,
lib64quadmath0, lib64stdc++6, lib64ubsan0, libc6-dev-amd64.
If you install gcc-7-multilib for non-default architecture (i386 or x32),
it will inevitably pull libc6-amd64.
If we removed libc6-amd64 at all, it would cause problems building amd64
packages on i386 system. We could make those lib64* packages dependent on
libc6:amd64 instead, but that would break if the user has i386
installation and he doesn't have amd64 foreign architecture set up.
It would be best to set it up so that libc6-amd64 doesn't install any
files only if libc6:amd64 is present. Could it be done with the deb
format?
Mikulas
Reply to: