This is a very specific question which google didn't help answering.

I'm running Ubuntu 13.04 with apt for amd64 compiled on Oct 3 2013 15:25:56.

I want to install Erlang from a .deb package, but I don't want to pull all of its dependencies. The package itself specifies that it depends on Java and wx libraries, but in reality those are not needed unless you want to interface with Java or wxWidgets.

I can install Erlang like this

sudo dpkg -i --force-depends erlang.deb

However, installing anything else with apt-get afterwards fails because of unmet dependencies. So if I want to install git after Erlang, I get the following

$ sudo apt-get install -y git
Reading package lists...
Building dependency tree...
You might want to run 'apt-get -f install' to correct these:
The following packages have unmet dependencies:
 esl-erlang : Depends: default-jre-headless but it is not going to be installed or
                       java2-runtime-headless or
                       java1-runtime-headless or
                       java2-runtime or
              Depends: libwxbase2.8-0 but it is not going to be installed
              Depends: libwxgtk2.8-0 but it is not going to be installed
              Recommends: erlang-mode but it is not going to be installed
 git : Depends: libcurl3-gnutls (>= 7.16.2-1) but it is not going to be installed
       Depends: perl-modules but it is not going to be installed
       Depends: liberror-perl but it is not going to be installed
       Depends: git-man (> 1: but it is not going to be installed
       Depends: git-man (< 1: but it is not going to be installed
       Recommends: patch
       Recommends: rsync
       Recommends: ssh-client
E: Unmet dependencies. Try 'apt-get -f install' with no packages (or specify a solution).

Is there a way to make esl-erlang package shut up without running apt-get install -f?

I want something like this:

sudo apt-get install --ignore-deps-for-package=esl-erlang git

or like this:

sudo apt-cache shut-package-up esl-erlang

or this:

sudo apt-get download git
sudo dpkg -i --with-deps git.deb

I've found a similar question: https://serverfault.com/questions/250224/how-do-i-get-apt-get-to-ignore-some-dependencies. A couple of answers provide handy manual steps to modify dependencies of certain packages.

I'm still looking for a robust automated method.

  • Have you tried --nodeps (apt-get) or --ignore-depends with dpkg?
    – Mike Koch
    Apr 8, 2014 at 20:24

3 Answers 3


I understand bjanssen's point, but it seems ridiculous for a package manager to allow --force-depends for a single package install, but not allow force-depends-forever-and-stop-warning-me-about-this-dependency.

I had a similar problem with a package which depended on a libcairo version slightly higher than the one currently available in Debian. For my purposes it still works fine. I'm happy to keep using it until the libcairo update appears in apt. I don't want to compile from source or build my own package.

The solution I found:

  • edit /var/lib/dpkg/status,
  • find the package with the broken dependencies
  • edit the Depends: line to stop the package complaining.

I assume that will be overwritten the next time the package is updated, but that's exactly what i want.

  • 3
    This is perfect, just what I needed to temporarily workaround an incorrect PPA dependency!
    – Cas
    Jan 24, 2017 at 14:20
  • Can this be done from a script?
    – mvorisek
    Mar 19, 2020 at 14:42
  • 1
    Scripting the edit to the status file would be easy. You could do something like run a global update, grep for every package with "Unmet dependencies", edit the status file, re-run the global update. But that seems dangerous, and too long for a comment. If you can explain your reason, ask for it in another question! Mar 20, 2020 at 2:28
  • I had to remove the Breaks: line for the faulty packages.
    – philant
    Sep 28, 2021 at 7:38
  • 1
    Just so you know: Gentoo has this functionality built-in (A simpl list in /etc/portage/package.provided), and it really is apt being a horribly outdated package manager. You’re not crazy. They are.
    – anon
    Dec 15, 2022 at 14:11

What you try to do is against the purpose of a package manager, which tries to keep a sane environment, i. o. w. you are using the wrong tool for the job. Don't try to break apt-get.

The right way to solve your issue is to build your own package with dependencies that suit you. There is the official way (quite involved: http://www.debian.org/doc/manuals/maint-guide/index.en.html) and the quick and dirty way using apt-build, or for packages not in the distribution source, checkinstall. All produce packages apt-get will happily install.

On a final note, you may question the wisdom of the maintainer of esl-erlang to include certain dependencies, but you cannot fault the package manager for intended behavior. If you think these dependencies are wrong, you should file a bug with the package.

  • What you've said about the "purpose of a package manager" is basically true, but you shouldn't generalise either. I'd like to give an example: one application needed libmng1. But I had libmng2 installed AND a symlink set to libmng1.so. Worked a threat, never had any problems. But apt-get always complained about "unmet dependencies". So there is definitely a good reason trying to find a way to silence aptitude in this respect. Since things do work, it just keeps complaining for things that simply are no problem. It just sees problems where they aren't any. And that's annoying. Dec 15, 2014 at 2:25
  • This is a curious situation. I guess you installed a package from a non-distribution repository? In such a case take a look at equivs for "silencing" apt-get without breaking it.
    – bjanssen
    Apr 18, 2015 at 11:31
  • Well, it could have been like that. But in fact it wasn't ... I simply installed the older package from the very same distro, so in Ubuntu terms I was on 15.x, but I installed the libmng1 from 12.04 LTS. Apr 18, 2015 at 12:43
  • 1
    Please do not nanny users. This is not iOS or Windows. Linux users are expected to know what they are doing, and if they chose to do something, is it for good reason. Same difference as an IKEA 0.5N electric screwdriver VS a Hilti pneumatic hammer drill. Questioning their choice without basis, is not acceptable. // In this case, their good reason was that the repository data was bad or broken, and APT is too ancient to allow easy dealing with it. (E.g. in Portage, there are several trivial ways to deal with this.) So a well-justified question, with your first paragraph being out of place.
    – anon
    Dec 15, 2022 at 14:26

Check, if the "proxy used" in the apt.conf is proper (i.e. in accordance to your network). This causes such issues as well, since urls would be unreachable.

Typically, if you using proxy, then your /etc/apt/apt.conf would look like:

Acquire::ftp::proxy "ftp://<user>:<password>@<ip>:<port>/";
Acquire::http::proxy "http://<user>:<password>@<ip>:<port>/";
Acquire::https::proxy "https://<user>:<password>@<ip>:<port>/";

This site is temporarily in read-only mode and not accepting new answers.

Not the answer you're looking for? Browse other questions tagged .