Package management at the systems level is a completely different problem from package management at the application level. An externally-facing server application is ideally a self-contained system of its own which should be installable on any modern kind of system without regard to whatever is or isn't on that system already, beyond the bare minimum. Trying to resolve library dependencies between two externally-facing applications is pointless; there should be no effect of one on the other.
In the days when space and bandwidth was expensive, a lot of compromises had to be made, but with many current language ecosystems, the cost of maintaining separate infrastructure is trivial, so we shouldn't be continuing to make our lives more difficult by deferring to the system package manager.
The sibling comment brings up Nix, but the only reason that looks like a good solution is that it happens to make all libraries application-specific libraries (if I understand correctly), which fuses the two problem domains. Nix excepted, however, I think it's a mistake to conflate them.
Ugh. I think there's a lot of sense in this comment, but it still seems horrendously wasteful to install multiple, redundant versions of libraries just to maintain separation between applications.
Hell, space and bandwidth are cheap: Let's just distribute all of our applications as 2 GB binary VM images.
In the days when space and bandwidth was expensive, a lot of compromises had to be made, but with many current language ecosystems, the cost of maintaining separate infrastructure is trivial, so we shouldn't be continuing to make our lives more difficult by deferring to the system package manager.
The sibling comment brings up Nix, but the only reason that looks like a good solution is that it happens to make all libraries application-specific libraries (if I understand correctly), which fuses the two problem domains. Nix excepted, however, I think it's a mistake to conflate them.