0
root@kali:~# apt-get dist-upgrade

 Reading package lists... Done

 Building dependency tree 

 Reading state information... Done

 Calculating upgrade... Error!

 Some packages could not be installed. This may mean that you have

 requested an impossible situation or if you are using the unstable

 distribution that some required packages have not yet been created

 or been moved out of Incoming.

 The following information may help to resolve the situation:

The following packages have unmet dependencies:

 libc6-dev : Breaks: libgcc-8-dev (< 8.4.0-2~) but 8.2.0-14 is to be installed

E: Error, pkgProblemResolver::Resolve generated breaks, this may be caused by 
held packages.
DavidPostill
  • 162,382
Marwan Ibrahem
  • 11

2 Answers2

1

This is an apparent bug with the gcc-10 packages in Debian: they renamed a package and removed the transitional packages before the release of Bullseye. The following packages were renamed (to match stated convention/debian policy more closely, I think):

  • libgcc1 -> libgcc-s1
  • lib64gcc1 -> lib64gcc-s1 (on 32 bit architectures only)
  • lib32gcc1 -> lib32gcc-s1 (on 64 bit architectures only)
  • libx32gcc1 -> libx32gcc-s1 (on x86_64 only)
  • a few others on less common arches

The newly-renamed packages have a Provides: libgcc1 (etc.) property, but it appears that apt is preferring a real (old) libgcc1 package over a virtual package that is only "provide"d by the newer package, since it's trying to not break your system. I am not familiar with the details of the internals of dependency resolution and installation order, but that's how I understand the problem anyway.

The way to really solve the problem, at least until a fix in the distro, is to provide "real" (but empty "transitional") packages named using the old name, that depend on the package's new name. I have done this over at https://salsa.debian.org/rpavlik/gcc-10-compat (including a repo to add with the packages). There's more details about the problem, and instructions to use my workaround, over there.

Since I know link-only answers are frowned upon, here's approximately what my workaround effectively does:

You can use the equivs package to make your own empty packages. (You may need to do this on a different system or undo your repo changes, to be able to install equivs!) Once equivs is installed, you'll want to do something like this for each of the package renames:

# create equivs control file named libgcc1
equivs-control libgcc1.control

edit equivs control file: you will need to set:


- "Package" name to the old name


- "Version" to something larger than the old version: 10.1.0-1 works


- "Depends" to the new name


nano libgcc1.control


Build a package - add --arch i386 to make a 32-bit build


equivs-build libgcc1.control

You will then need to put this into an apt repo: do not just install it directly because these will replace the essential, real libgcc, which will keep you from running apt! Making a repo is beyond the scope here, check another question or just use the repo I already made.

Once these new "transitional" libgcc1 etc. are available in an apt repo and you update your sources to choose bullseye, apt will be able to dist-upgrade/full-upgrade correctly, and you can remove the transitional packages after the upgrade is done.

Rylie Pavlik
  • 245
  • 2
  • 6
0

This is problem with your repository. Login as a root user and update your repository. Open terminal and run

gedit /etc/apt/sources.list

Replace the old repository with the new repository, save and run

apt-get update 
apt-get install -f
apt autoremove
apt clean
Ruby
  • 100