5

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. Also,

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

closed as primarily opinion-based by roaima, Michael Homer, G-Man, cuonglm, slm Aug 1 '15 at 3:52

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

  • cc -static -o prog prog.c will statically link the output executable binary. And not everybody writes inherently independent software. If you'rre very interested in small, statically linked executables maybe checkout suckless.org - there are a lot of software packages there which build into single, portable executable binaries. And anyway, BSD's ports tree is maintained in such a way that the dependencies can't not exist - all of the makefiles are maintained together. You can't put a package in ports without putting all its dependencies in along with it. – mikeserv Jul 31 '15 at 19:07
  • 2
    Which version of Windows were you using!? Don't you remember DLL Hell? – garethTheRed Jul 31 '15 at 19:10
  • Actually as long as soname of a library haven't change, all minor versions within are supposed to be compatible. If for some library that isn't the case, it is more likely a bug; then you can either hack rpath of an application, and point it to the library version you want, which itself have to be somewhere outside of the run-time linker scope. Either pin the library (which is more appropriate since it is a library bug). Libraries with different soname's you can install in a standard way without a problem. – Hi-Angel Jul 31 '15 at 20:56
  • @garethTheRed: which Linux are you using? Noticed glibc hell, yet? Honestly, I always thought that DLL hell was pretty harmless compared to the nasty stuff I am encountering (as developer and admin) with glibc. Not at last because of licensing and mixing licenses. Ermine/Statifier promise solutions, but those create rather more problems when it comes to licensing. – 0xC0000022L Jul 31 '15 at 21:06
  • 1
    The nix package manager is an interesting solution to this. You can also go with a distribution with a long support policy (such as Red Hat/CentOS), which maintains the same version of installed packages for 10 years or more. – Mark Plotnick Aug 3 '15 at 17:14
6

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.

  • When was the last time you tried to build software to run on older Linux distros without building on the older Linux distros, but instead trying to link to the older glibc and so on? The ABI allows to a limited extent (and when it works) older programs to run on newer systems, but the other way around things get really messy. Side-note: Windows, i.e. a live CD, requires ~200 MB. And that's a relatively modern Windows 7 or 8. You're talking about the bloat that comes installed by default. – 0xC0000022L Jul 31 '15 at 21:14

Not the answer you're looking for? Browse other questions tagged or ask your own question.