Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I installed a Amsynth from Lucid in Karmic using:

dpkg --force-depends-version -i amsynth_1.2.2-1_i386.deb

The reason for installing the Lucid version is because Karmic version is 3 years old and crashes on my machine. The Lucid Amsynth package depends on newer versions of libatk1 and libjack0 than Karmic has, but I thought I would take a risk, and turns out Amsynth runs fine.

However aptitude tries to uninstall Amsynth every time I do an upgrade. I think I've managed to put it on hold but now aptitude aborts. How can I tell aptitude to ignore the broken package and carry on.

share|improve this question
    
For the moment I've just uninstalled it. I'll just reinstall each time I need it again, it doesn't take too long, up until it bugs me enough to try compiling it again. –  Rudolf Jan 18 '10 at 16:14
    
If you need something from newer release and it needs newer libraries, you can usually either just pull them along or download the source package and rebuild it on your system. However I've come across this trying to use a 3rd party package and than the hacks are needed. –  Jan Hudec Jan 28 at 19:52

3 Answers 3

In aptitude's Preferences section (Ctrl-T to get into the menu; under Options), uncheck the option in the "Dependency Handling" section that says "Automatically fix broken packages before installing or removing". That should make aptitude stop trying to fix the package each time you change other packages.

As a more permanent fix, you should grab the source packages for the Lucid Amsynth package you installed, as well as source packages for libatk1 and libjack0, and build your own updated package. Depending on what else uses those libraries, you might need to update other packages as well, but you can probably get away with just those. (This is essentially backporting those packages from Lucid to Karmic -- you should check the Karmic-backports repository or the PPAs to see if anyone's already done this. If your new packages work, consider sending them to Karmic-backports for others to use.)

share|improve this answer
    
Thanks I tried your first suggestion but it didn't seem to make a difference. Updates would just abort. I also tried compiling it before I tried installing the Lucid package but had no luck with it. I might try again in the future. –  Rudolf Jan 18 '10 at 16:10

There's a hacked solution at the Ubuntuforums. ~quack's solution is better, but more work.

I couldn't find anything on google about this, save compiling your own 'dummy package' (impossible without uninstalling the broken package(s). unless you are lucky enough to already have the tools), but searching my own hard drive gave me the answer eventually!

For anyone who'd like to know, here's how to "unbreak" a package in synaptic / aptitude / apt-get, without uninstalling it.

First of all, make a note of the package you installed, and the package(s) it depends upon that give it a broken status. Say I forced an install of apples, which depends on the package obsolete which isn't in the repository :

In a terminal type Code:

sudo gedit /var/lib/dpkg/status

search the file for apples until you find something like :

Code:

Package: apples
Status: install ok installed
Priority: optional
Section: libs
Installed-Size: 316
Maintainer:
Architecture: i386
Source: applesauce
Version: 1.0.10-1
Depends: packageA, packageB, obsolete
Description: Apples on your desktop!

Remove obsolete from the Depends: row, save the file, and you're done. Hope this helps some people out.

share|improve this answer
    
ick. good find, but i'm not a fan of lying to the package manager (which is essentially what that hack does). better to not use APT at all than to run around breaking it willy-nilly. this is why compiling your own packages is a good thing -- no broken dependencies and no lying to your package manager. –  quack quixote Jan 14 '10 at 0:18
    
I have no problem with lying to the package manager, especially since in a few months I'll be reinstalling the OS, but I couldn't find the file referenced in the thread. –  Rudolf Jan 18 '10 at 16:12
    
Weird. It should be there. Try doing "cd /var/lib/dpkg" and then "sudo nano status". –  Iain Jan 18 '10 at 16:46
1  
The link no longer works. Which is the exact reason why link-only answers are frowned upon around here. If you explained here, it would be the correct answer. –  Jan Hudec Jan 28 at 19:50

If you installed the program via a deb-file and dpkg, you could also alter the dependencies of the installed .deb file manually. I was driven to this extreme measure once ...

ar x foo.deb
vim control.tar.xz  # see below
ar r foo.deb control.tar.xz
dpkg -i foo.deb

and dpkg does not know about the dependencies of foo anymore. In vim you have to select ./control (I use vim to read packed files -- unpack and use another editor and repack if you like) and remove the unwanted dependencies from the line

Depends: foo bar
share|improve this answer
    
You're better off using dpkg-deb rather than ar. ar is a dpkg implementation detail that may change in the future. –  jmtd Apr 19 '13 at 6:51

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.