23

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

I'm running Ubuntu 13.04 with apt 0.9.7.7ubuntu4 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
                       java1-runtime
              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:1.7.9.5) but it is not going to be installed
       Depends: git-man (< 1:1.7.9.5-.) 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.

Community
  • 1
android
  • 331
  • 1
  • 2
  • 6

3 Answers3

40

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.

muru
  • 1,195
  • 9
  • 33
andrew lorien
  • 551
  • 5
  • 11
  • 3
    This is perfect, just what I needed to temporarily workaround an incorrect PPA dependency! – Cas Jan 24 '17 at 14:20
  • Can this be done from a script? – mvorisek Mar 19 '20 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! – andrew lorien Mar 20 '20 at 02:28
  • I had to remove the `Breaks:` line for the faulty packages. – philant Sep 28 '21 at 07: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. – Evi1M4chine Dec 15 '22 at 14:11
  • What we need here: Is there a way to trigger a script on installation of a package? To fix the mess that grandpa apt once again made. – Evi1M4chine Dec 15 '22 at 14:28
1

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.

bjanssen
  • 2,429
  • 15
  • 14
  • 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. – syntaxerror Dec 15 '14 at 02: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 '15 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. – syntaxerror Apr 18 '15 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. – Evi1M4chine Dec 15 '22 at 14:26
0

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>/";
parasrish
  • 101
  • 4