[SOLVED] How do I fix "Unmet dependencies" endless loop (Debian).

spikeygg · 08-25-2012, 03:05 PM

So this morning I did a apt-get dist-upgrade and it worked for a while and eventually errored with a dependency failure. Now whenever I try to apt-get install any packages it just says:

Code:

Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run 'apt-get -f install' to correct these:
The following packages have unmet dependencies:
 kde-baseapps-data : Breaks: kdebase-data (< 4:4.7.2) but 4:4.6.5-1 is to be installed
 konqueror : Depends: kdebase-bin (= 4:4.6.5-1) but 4:4.8.4-1 is to be installed
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).

So I try to run what it suggests to fix the problem dependencies and it fails with this:

Code:

$ sudo apt-get -f install
Reading package lists... Done
Building dependency tree
Reading state information... Done
Correcting dependencies... Done
The following extra packages will be installed:
  kde-baseapps-data konqueror
Suggested packages:
  konq-plugins
The following packages will be REMOVED:
  kdebase-data
The following NEW packages will be installed:
  kde-baseapps-data
The following packages will be upgraded:
  konqueror
1 upgraded, 1 newly installed, 1 to remove and 224 not upgraded.
3 not fully installed or removed.
Need to get 0 B/1,682 kB of archives.
After this operation, 380 kB disk space will be freed.
Do you want to continue [Y/n]?
Reading changelogs... Done
(Reading database ... 154231 files and directories currently installed.)
Preparing to replace konqueror 4:4.6.5-1 (using .../konqueror_4%3a4.8.4-1_i386.deb) ...
Unpacking replacement konqueror ...
dpkg: error processing /var/cache/apt/archives/konqueror_4%3a4.8.4-1_i386.deb (--unpack):
 trying to overwrite '/usr/share/doc/kde/HTML/en/konqueror/format-font-size-less.png', which is also in package kdebase-data 4:4.6.5-1
configured to not write apport reports
                                      dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Processing triggers for man-db ...
Processing triggers for desktop-file-utils ...
Processing triggers for gnome-menus ...
Processing triggers for hicolor-icon-theme ...
Errors were encountered while processing:
 /var/cache/apt/archives/konqueror_4%3a4.8.4-1_i386.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

Then it gives me back the console, apparently not completing any fixes. What do I need to do to fix this?? I'm so confused.

Thanks,
-Greg

jlinkels · 08-25-2012, 03:16 PM

Install that one package forcing overwrites.
dpkg -i --force-overwrite /var/cache/apt/archives/konqueror_4%3a4.8.4-1_i386.deb
and then repeat apt-get install -f

This is somewhat risky and could break your system. But if you don't do it, apt won't proceed past this point ever, and neither allow you to install anything else.

From what to what are you dist-upgrading? From Lenny to Squeeze this tended to happen a few times, so you might have to repeat this trick a few times for various packages.

jlinkels

spikeygg · 08-25-2012, 03:39 PM

Quote:

Originally Posted by jlinkels

Install that one package forcing overwrites.
dpkg -i --force-overwrite /var/cache/apt/archives/konqueror_4%3a4.8.4-1_i386.deb
and then repeat apt-get install -f

This is somewhat risky and could break your system. But if you don't do it, apt won't proceed past this point ever, and neither allow you to install anything else.

From what to what are you dist-upgrading? From Lenny to Squeeze this tended to happen a few times, so you might have to repeat this trick a few times for various packages.

jlinkels

Thanks jlinkels! that did the trick. I think I was on Squeeze and now I'm on Wheezy/Sid. I'm trying to get libc2.15 installed due to an error I've been getting trying to get a program running:

/lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found

Any idea how I could go about getting the 2.15 version? I thought a dist-upgrade might rev it up but no such luck.

Thanks again!
-Greg

David the H. · 08-25-2012, 04:04 PM

Usually it's safer to just delay the upgrade (of the packages in question, at least) for a few days. Dependency conflicts tend to be temporary issues, caused when one updated package gets into the repository earlier than the other(s) it depends on. This almost always gets sorted out within a day or two.

dist-upgrades might conceivably take longer, as I'm not sure about how quickly those conflicts specifically get resolved, but I'm sure it's not too long either.

craigevil · 08-25-2012, 05:28 PM

It was a known bug with konqueror that is a few months old. Forcing it is the only fix.

jlinkels · 08-26-2012, 08:23 AM

Even in sid libc is only at version 2.13. I wonder what cutting edge program you try to run. It is possible that your application demands 2.15 while it would be satisfied with an earlier version. Maybe there is a way to fake a program into thinking that the library version is different but that it beyond my knowledge.

Obviously, you can always try to recompile the program yourself.

jlinkels

spikeygg · 08-26-2012, 10:02 AM

Quote:

Originally Posted by jlinkels

Obviously, you can always try to recompile the program yourself.

Hah, it's funny you should say that. I compiled it from source on another machine. I just upgraded my main server and it's now running Ubuntu (precise) which is, apparently, running libc6 of 2.15. I use this machine to compile the binaries for a few of the other machines in my house but I guess I'm going to have to downgrade the libc6 version that is running to compile these binaries. :-/

To do that I can just install the older version on my main server and use a environment variable (or two) to make it use the version I want, right?

I really didn't expect an upgrade to Ubuntu to cause such a ripple effect in my methods.

jlinkels · 08-26-2012, 11:10 AM

I have too little experience in compiling packages to be in a position to advice you how to set environment variables right. And yes, it is a PITA that you can't run compiled binaries easily from one machine to the other.

jlinkels

David the H. · 08-26-2012, 11:27 AM

Quote:

Originally Posted by jlinkels

Maybe there is a way to fake a program into thinking that the library version is different but that it beyond my knowledge.

Coincidentally enough, I was doing just that this morning trying to get the Trinity Desktop to install on my newly-reinstalled sid system.

Sometimes when libraries update they increment the library/package name, not just the version number, so the Trinity packages (compiled for squeeze) were being held up by some outdated package names, e.g. I discovered that it wanted libaudiofile0, while sid is now using libaudiofile1.

Fixing it was a two step process. First, I used apt-equivs to create a dummy package for libaudiofile0, as described here:
http://eric.lubow.org/2010/system-ad...ges-on-debian/. This allowed the packages to install, at least.

Then I went in and created a symlink to the new library files, i.e. "ln -s /usr/share/x86-64/libaudiofile.1 libaudiofile.0", that way the programs are able to access the library that is actually installed (you can use ldd to discover the exact library name a given binary wants).

It's not a technique I recommend for beginners, and to tell the truth I was half guessing some of it myself. I had to do some detective work to discover which libraries were blocking, and some trial and error when creating the equivs. Naturally there's also a chance for incompatibilities between the library versions, and I don't know what will happen when I next need to upgrade. But for now, at least, I have a working desktop.

In any case, if you build a library from source, then you should be able to use the same technique to create a dummy package for anything that depends on it.

(Speaking of which, I also recommend using checkinstall to package your source compiles into .deb packages, for easy management.)