0

I spent a few hours trying to install a package and didn't succeed; it seems like that just happens sometimes in a Linux environment.

Background: The package I want to install is available as 1) a .deb for x86 instead of x64, 2) a .Run, 3) source, and 4) an OSX installer. The OSX installer just works. On a fresh install of Debian 7, I have tried the .deb, the .Run, and compiling from source. All three led me through a series of hoops. The most basic problems appear to be that via any of these routes Debian 7 gave me too old a version of LibC and too old a version of Ocaml. Most of my time was spent executing one apt-get command after another trying to resolve dependencies.

Question: What are some tools that make it easier to install packages by automating as much of the process as possible? All packages, even building from source, make it clear which versions of which dependencies they require, right? So why can't all the dependencies just be resolved automatically?

I would be happy to even just make a directory on my system that contains a copy of every single dependency that my package requires so that it can run in its own little environment without modifying the versions of other packages on my system; I'm not sure if that's possible. I'm positive there must be SOME way to just say "give me the package called Foo, version 4.2.3" and have everything else done for me.

themirror
  • 6,988
  • You're describing a package manager pretty exactly, do they not work? – Michael Mrozek Sep 27 '13 at 16:00
  • @MichaelMrozek maybe my problem is just that the package I want to install is not in any package repository. But what I'm asking is, what are some tools I can use to reduce the amount of guesswork involved in resolving dependencies and make installing any package closer to the experience of running an OSX installer. – themirror Sep 27 '13 at 16:03
  • 4
    Tell us what package it is, maybe someone has experience with it. – schaiba Sep 27 '13 at 16:41
  • Most packages aren't tied tightly to libc. Wonder what package this is. – Faheem Mitha Sep 27 '13 at 18:51

2 Answers2

1

The experience is pretty much identical. Your problem is that Debian (stable) is not a cutting-edge distro, it is stable. This means that it will have older versions of packages in its repositories (it might be a good idea to mention the package name by the way). Your are comparing it to a new version of OSX which has newer versions of essential libraries like libc.

Installing .deb packages that have been packaged for the version of Debian that you are running is very easy and painless. Believe me, I used to have to install most things from source. When you run aptitude install foo.4.2.3.deb you are saying "give me the package called Foo, version 4.2.3" and have everything else done for you. If it is not in the repos because you are using an old version, that is not the package manager's fault.

So, I would recommend posting a new question and asking how you can install the specific package you are attempting to get. Bear in mind, that if it requires a newer version of libc it is probably easier to upgrade your entire system to the testing or experimental repositories. While it is possible to only upgrade libc it is neither easy nor straightforward, see here.

Also, you should be aware that this is not a trivial problem. While dependencies are managed very well by package managers, they can conflict. Especially when working with something as basic as libc.

This command will print out a list of packages that depend on libc. 

apt-cache rdepends libc6

On my Debian, that list contains 16056 different packages. If you upgrade libc because package foo depends on a newer version, how should the package manager deal with the fact that 16056 packages depend on the installed version? How can it know if they will also be compatible with the newer version?

Community
  • 1
terdon
  • 242,166
  • "Also, you should be aware that this is not a trivial problem. While dependencies are managed very well by package managers, they can conflict." -- what about the part where I ask if I can just install a package and all its dependencies to a special directory without upgrading/affecting any other packages on the system? – themirror Sep 27 '13 at 17:34
  • @themirror see the link I posted in my answer. The proceedure is explained there. – terdon Sep 27 '13 at 17:38
  • @terdon libc is mostly backwards compatible. Except for things very tightly bound to it (e.g., NSS modules), it can probably be upgraded without issue. – derobert Sep 27 '13 at 19:32
0

I'd like to just chime in here and say that I think that your expectation is just wrong.

The solutions are targeting 2 completely different audiences. Apple tightly controls what software is available and it's a narrow sliver of applications.

I've helped more people that I care to admit that were using an OSX system where they wanted to install opensource project "X" and they were going through all the same types of hoops on OSX with the wrong version of Xcode, or they were using the official version of subversion, and needed to install a version from MacPorts or HomeBrew. There was literally no difference in fighting with the different libraries and dependencies until you could get this package "X" installed.

There is no magical tool that I've ever seen that will just let you put the dependencies in a directory and install application "X". It just doesn't exist and chances are never will. There have been a number of attempts to make dependency management and package management better and it's just a extremely complicated problem to solve.

Apt, Yum, etc. all do a decent job of it but the problem is they're attempting to solve an unbound problem, which is usually impossible. You can only get 80% types of solutions to it, or solutions that work for "most" of the cases.

It's as simple as that.

slm
  • 369,824