We did something like this 20 years ago at a company I worked for. It's effectively pointless, and there are better, more modern methods. Here's why.<p>First of all, the filesystem isn't a database, it's a hierarchical index of files. It has a couple fancy features specific to managing files. Trying to force it to do more than that will result in pain, and eventually building something else around it. But the filesystem isn't even the biggest limiting factor.<p>Managing both the build-time and run-time dependencies of software is more complex than a filesystem can handle. To execute an application in an operating system, there must be one "environment", which is a combination of a kernel, an OS's environment and resources, and a set of applications and dependencies. The dependencies are set at build time and run time, and can't be interchanged at will without causing instability (if it works at all). You can juggle symlinks around all you want, but it doesn't result in any useful functionality other than looking at a bunch of differently versioned files that are not - <i>cannot</i> - be in use.<p>The <i>applications themselves</i> can be programmed to interact with multiple versions of dependencies, but if they are not already built to do so, you cannot force them to. This underlying limitation is what forces an application environment to depend on a static tree of files. It doesn't matter how many versions of a dependency you have installed, you can only use one at a time, as each application allows you to. That's why you can only install one version of a package, and why we don't have trees of versioned file hierarchies for the dependencies. They'd be pointless. You can only use the files you can use.<p>All popular Linux distributions today know this. They have worked along with the Linux Filesystem Hierarchy Standard over the past 26 years, and understand these issues well. Distros may implement it differently, but mostly they conform to it, because they know nothing else really makes a difference. At the end of the day, the current standard (when properly used) is as simple and effective as we can get.<p>Some software developers (<i>cough</i> Systemd <i>cough</i>) basically don't give a shit about the standard, and generally make the users' and distros' lives harder. This is the one place where the distros could make a difference, by forcing a structure that makes more sense. But enforcement is haphazard, so some apps can force really stupid file structures on distros, and people wonder why the filesystem is so confusing.<p>So you may ask, what's a better solution? The answer is containers (or really, chroot environments, but that's what a container is). I have a longer post which goes into more detail about why package management literally cannot solve any other problem than it already does, and why containers are the only "advancement" without radically redefining application development: <a href="https://gist.github.com/peterwwillis/e96854532f471c739983c0bba7608834" rel="nofollow">https://gist.github.com/peterwwillis/e96854532f471c739983c0b...</a>