reassign -1 libgcc1
forcemerge 961990 -1
severity -1 important
retitle -1 Implicit conflict between libgcc1 and libgcc-s1 prevents upgrade
Hi,
On Sun, Jul 19, 2020 at 09:30:34PM +0200, Helge Kreutzmann wrote:
> reassign 964477 apt
That tends to be the worst thing you can do to such a bugreport, as it
is impossible for the tiny apt team to understand, test & debug all
50000+ packages in Debian and their inter-relations and the particular
ecosystems they life in.
> On Sun, Jul 19, 2020 at 06:58:33PM +0200, Aurelien Jarno wrote:
> > I guess apt developers might be able to help there.
… we can answer calls for help via CC though as that keeps the ball in
the playing fields (instead of hiding it in our off-field of ~900 open
bugs) – as regardless of what the reason for the error might be, even if
it is a colossal bug in apt, lacking a time machine those bugs can not
be fixed in apt/stable and hence the upgrade needs to work with the apt
version it got.
> > > > > If I try to remove either libc6-dev or libgcc-8-dev then a long list of
> > > > > programms is scheduled for deinstallation, e.g. lots of KDE, okular, libreoffice etc.
Just as a user does, apt also hates to remove packages, so its default
action is to try to keep them installed if it can (hint hint).
Anyway, I got a dpkg/status[0] file from a user with a similar problem.
For him it was:
| […]
| The following packages have unmet dependencies:
| libc6-dev : Breaks: libgcc-9-dev (< 9.3.0-5~) but 9.2.1-8 is to be installed
| E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by held packages.
| […]
as he is using unstable (although that machine wasn't upgraded for a few
months), but that "works" just the same for stable users in an upgrade
to bullseye.
The packages shown in that message do not matter that much though, as we
will quickly figure out that the resolver is giving up after 10 (or now
after 20) attempts (-o Debug::pkgProblemResolver=1 ending with
"Investigating (19) …") of figuring out that mess, so if its gcc-7, -8,
-9 or -10 just depends on what your installed libgcc1 requires.
Scrolling in that debug output to the top we will encounter:
| […]
| Broken libgcc1:amd64 Depends on gcc-9-base:amd64 < 9.2.1-8 -> 9.3.0-16 @ii umU > (= 9.2.1-8)
| Considering gcc-9-base:amd64 212 as a solution to libgcc1:amd64 735
| Added gcc-9-base:amd64 to the remove list
| MarkKeep gcc-9-base:amd64 < 9.2.1-8 -> 9.3.0-16 @ii umU > FU=0
| Fixing libgcc1:amd64 via keep of gcc-9-base:amd64
| […]
And that is in fact where all the trouble starts as apt decides that it
wants to keep libgcc1 installed because a lot of stuff depends on it,
which requires packages to be kept in an older version (or removed).
The problem here is that libgcc1 is an installed real package, but wants
to be in the future a purely virtual one provided by libgcc-s1. That is
confusing for apt and users alike. The two packages do not conflict
however, so the only reason these two can not co-exist on a system is
that you can't upgrade your system while keeping libgcc1 installed, but
libgcc1 seems important enough to not just remove it (at least on some
systems, especially those with many packages which will require a remove
in the same upgrade like lots of KDE packages in this case… libqtcore4
alone is worth 400 points).
I can see a bunch of solutions for this:
1. libgcc1 becomes a transitional package (looks like it was for some
time, no idea why that was dropped already).
2. The conflict is made explicit, e.g.:
libgcc-s1 Breaks libgcc1 (<< 1:10.1.0-1)
(results in the line: "Considering libgcc1:amd64 734 as a solution to
libgcc-s1:amd64 6545", so libgcc-s1 wins this by a long shot)
3. stable upgrade instructions are provided: apt full-upgrade libgcc1-
(hundreds of users will not read them and complain all over the place)
That is, incidently, the order of my personal preference, but that is up
to the involved maintainers to decide and test as they will know best
what is working for their packages and ecosystems.
(I guess I could argue that not doing 1 or 2 is a policy violation as
libgcc-s1 takes over a file from libgcc1 without ensuring that libgcc1
is upgraded to a version without that file (or removed) and instead
relies on it being removed due circumstances, but I am not in the mood
for policy text dissecting)
Best regards
David Kalnischkies
[0] /var/lib/dpkg/status from before the performed upgrade, so usually from
/var/backups as users tend to modify the systems while working around.
Attachment:
signature.asc
Description: PGP signature