TL;DR: I think language-centric package managers do a better job at versioning packages per-project. Here's an anecdote to explain what I mean.
-----
Let's say I want to build a piece of software that depends on some software library written in C at version 1.0.1. It's distributed through my system package manager, so I sudo apt-get install libfoo.
~~ some time later ~~
Now let's say I want to build a different piece of software that also depends on foo, but at version 1.2.4. I notice that libfoo is already installed on my system, but the build fails. After a quick sudo apt-get install --only-upgrade libfoo. This piece of software now builds.
~~ Even later ~~
When I revisit the first project to rebuild it, the build fails, because this project hasn't been updated to use the newer version yet.
I'm fairly inexperienced with system package managers, but this is the wall I always hit. How should I proceed?
I'm arguing that you should just have one package manager, so in my world the only way for this to happen is if both the packages you're installing are tarballs that no one has bothered to port to your system. If the language-specific package manager did not exist, then there would be a better chance the package would exist for your OS already.
Anyway, Debian/Ubuntu has multiple fallbacks for this situation:
a. ppa's
b. parallel versions for libraries that break API compatibility (libfoo-1.0...deb, libfoo-1.2...deb that can coexist).
c. install non-current libfoo to ~/lib, and point one package at it (not really debian-specific)
d. debootstrap (install a chroot as a last resort -- this is better than "versioning packages per-project" from an upgrade / security update point of view, but worse from a usability perspective -- you need to manage chroots / dockers / etc).
I suspect the per-project versioning system is doing b or d under the hood. b is clearly preferable, but hard to get right, so you get stuff like python virtual environments, which do d, and are a reliability nightmare (I have 10 machines. The network is down. All but one of my scripts run on all but one of the machines...)
A long time ago, I decided that I don't have time for either of the following two things:
- libraries that frequently break API compatibility
- application developers that choose to use libraries with unstable APIs that also choose not to keep their stuff up to date.
This has saved me immeasurable time, as long as I stick to languages with strong system package manager support.
Usually, when I hit issues like the one you describe, it is in my own software, so I just break the dependency on libfoo the third time it happens.
When I absolutely have to deal with one package that conflicts with current (== shipped by os vendor), I usually do the ~/lib thing. autotools support something like ./configure --with-foo=~/lib. So does cmake, and every hand-written makefile I've seen.
-----
Let's say I want to build a piece of software that depends on some software library written in C at version 1.0.1. It's distributed through my system package manager, so I sudo apt-get install libfoo.
~~ some time later ~~
Now let's say I want to build a different piece of software that also depends on foo, but at version 1.2.4. I notice that libfoo is already installed on my system, but the build fails. After a quick sudo apt-get install --only-upgrade libfoo. This piece of software now builds.
~~ Even later ~~
When I revisit the first project to rebuild it, the build fails, because this project hasn't been updated to use the newer version yet.
I'm fairly inexperienced with system package managers, but this is the wall I always hit. How should I proceed?