Earlier quoted context omitted.
A mounted FS per installed application so you can run different versions side by side. I like it for large standalone apps, less so for command-line utilities. It easily beats untarring some third-party thing to /opt.
> A mounted FS per installed application so you can run different versions side by side. Does it strike anyone else as very telling that people looked at the problem of "we can't install more than one version of an application at a time because of how we structure our filesystem and hardcode paths" and decided that the solution was "let's give each application its own filesystem!"?
You can implement that versioned dependency DAG as a database of versioned libraries etc. combined with a version pinning database; or you can simply use disk space, and keep a copy of every dependency and put each in its own subtree, making the version pinning database implicit in the tree construction.
I don't see the latter solution as being intrinsically worse than the former. I don't think there's a real alternative either; the most reliable set of dependencies is the same set as the original binary was built and tested with.
(And of course it's not just libraries, but also configs of various flavours, assets, etc. If you didn't use the subtree approach, you'd need to reimplement it in a shim layer to simulate it, in order to package yesterday's applications today.)