Dependency hell: Why not create portable applications

Back in time to the ages when I was using Windows, applications were installed in an independent way. This left a lot of freedom to the end user/sysadmin to decide what and where to upgrade, what to patch and when without interfering other apps.

In *NIX, entangled dependencies are a painful headache. PC-BSD tried to overcome this with PBI, by creating self-contained applications.
AFAIK, this seems now deprecated and they returned to the package management way (PBI is now a wrapper for ports), and all the Linux distros run in the same direction: hundreds of dependencies to the very end, even Desktop Environments are expected to depend on system management daemons .

Building apps based on hundreds of dependencies makes programmers life easier, but creates a shocking problem to end users and sysadmins. For instance, I can’t keep an ancient Debian Etch version of app running in Debian Jessie any more.
I know that many people will come with the tale of security and patches and up-to-date systems, but OpenSource means freedom to determine what, when and where to update. There are very valid reasons to not update a system or part of it, or at least not to do it the way that typical *NIX package managers are conducting users (i.e. machines working offline, old hardware, compatibility with old data that needs to be kept for compliance, …). Other times, sysadmins prefer to make it in several steps for security.

Personally, I believe that me as sysadmin should decide what to update, and when, and bear the risk. With current state of affairs, this is impossible. (I.e having a new version of libc6 in Debian, this has dependencies everywhere). If I decide to keep two or more repositories to overcome the problem, I generate another nightmare.

I understand that certain dependencies (i.e. having MySQL installed), are acceptable as this is a major dependency, but I can’t understand why the tiny dependencies like libraries are not simply embedded in the code. Disk is cheap. Many Linux apps ported to Windows achieved this.

EDIT: to ensure it is not just opinion based

What are the options to install a software in *NIX (let’s put it Debian/FreeBSD for simplicity) in order to:

  • Keep a single certain version of a software running for years without upgrade and ensure that can be kept untouched regardless of the subsequent base OS and libraries upgrade, ala apt-get hold but forever.

  • Decide to upgrade/downgrade without conflicting other software/libraries.

  • Install two or more versions of that software.

Jails/chroot/VM’s are not options, although they are the evident workarounds.

  • What specifically made PBI to fail to achieve this independence goal returning to ports/package management?
Asked By: null_pointer


I can’t answer why PBI wasn’t successful, but I can answer why shared libraries are preferred in Linux.

The major argument is security, that if there is a vulnerability in a commonly-used library, then only that library has to be updated, and not all of the applications that use that library (thanks to ABI compatibility). This also means that (if you stick mostly to the main repos and PPAs (in the case of Ubuntu)), you don’t have to have 4 different versions of a library installed just because your applications were compiled against those versions (like Windows, where you would probably have different versions of the .NET libraries installed, or different versions of the visual C++ runtime installed).

That being said, though, there may be some cases where applications are not forced to use the system version of libraries and can instead use their own version. For example, Chromium depends on many libraries that are present in most distro’s repos. Under normal circumstances, applications would be compiled so that the libraries that they used were the ones that were compiled by the distro. However, in Ubuntu (at least), Chromium is compiled with its own version of libraries, because:

  • Using the system version of libraries means that Chromium would have to be tested for each release of Ubuntu.
  • Chromium is, for the most part, using the latest versions of libraries already, which means the likelihood of there being a vulnerability is much lower.

As for the disk space argument, you could argue that installing a debootstrap‘ed version of Debian Jessie requires less than 1 GB of disk space, making it great for smaller SD cards. Windows, on the other hand, requires at least several gigabytes of disk space.

Regarding older software, you could compile the application statically and have most of the dependencies self-contained. However, because your distro might not have static versions of libraries available (Debian and Ubuntu don’t, for the most part), you’ll need to compile those libraries on your own to get the static versions of those libraries.

Finally, one of the principles of Unix is that each application does only one thing, and is good at it. If applications and libraries were statically-linked, then they might be considered to be (indirectly) doing many things.

Answered By: saiarcot895