I don't want to start a war about static/dynamic linking / shared libraries, so: some people want some shared libraries for some reasons. One problem with havi

I don't want to start a war about static/dynamic linking / shared libraries, so: some people want some shared libraries for some reasons. One problem with having different applications use different versions of libraries is that you can have multiple versions of a library installed. Having multiple versions of a library installed undermines some of the reasons for using shared libraries in the first place. A lot of (most?) software was never meant to be used this way. It's uncommon to see an application that separates its data/config with unique filenames per version, for example. And there's not a global answer to whether or not that data should be shared between versions anyway. [0] Container-style software distribution largely avoids these issues by not having shared libraries[1] for the most part. This has some benefits like the sandboxing and security features and making consistent behaviour across environments more achievable[2]. But you miss out on benefits from using shared libraries. Surprise -- a software development decision is a trade-off! [0] Blender stands out for separating config files per version and also letting you easily import an existing config from an earlier version after an update. [1] or not sharing shared libraries [2] consistent behaviour across environments is more achievable as the dependencies are shipped with the application (you can ship dependencies without containers as well, e.g. static linking)