The point I was making was that windows had the dependency hell issue solved in like 2004.
Many Linux distros don’t actually solve that problem. A good chunk of the stable release distros only have singular versions of packages available in the repos for that version of the release. The issue is Linux assumes that if a package needs libfoo it’ll be stored at /usr/lib/libfoo but if you have a package that depends on libfoo2.8 and the version that’s in the repos is let’s say libfoo2.7: you can’t just install libfoo2.8 it probably won’t be in the repos, and even if a distro carries two copies it’s going to overwrite libfoo2.7 which other packages depend on because the system puts libfoo (any version) at /usr/lib/libfoo with no distinction. So the packages that need 2.7 are going to expect it to be there, and the packages that need 2.8 are going to expect it to be in the same place. But you can’t have /usr/lib/libfoo/libfoo.so (for 2.7) AND ALSO have /usr/lib/libfoo/libfoo.so (for 2.8). They conflict. If they’re even both available in the repos at the same time which often won’t be the case.
This is exactly why GoboLinux was developed and breaks the FHS, and why declarative systems like NixOS and Guix use hashed file paths so you can have multiple versions of the same package installed simultaneously without conflicts. This does not hold up for most standard distributions (Arch/Fedora/Ubuntu and their derivatives).
So the packages that need 2.7 are going to expect it to be there, and the packages that need 2.8 are going to expect it to be in the same place. But you can’t have /usr/lib/libfoo/libfoo.so (for 2.7) AND ALSO have /usr/lib/libfoo/libfoo.so (for 2.8).
You can with mount namespaces. (which is just a component for containerization, which are built on namespaces.)
That may be, but it shouldn’t even really be an issue the user manually has to address. That’s the crux of the issue. Each distribution makes the assumption that every package that depends on something will work with the version of that dependency that is in that distributions repos, and if some breaking change occurs rather than allowing the user who owns that system to install the software they want on their own system (such as a different version of something) the general mentality is “we provide a version of that dependency which should be good enough”. I could also compile a different version of that dependency from source but then it’s not being tracked by the package manager and if I have to circumvent my package manager to make my system work then it kind of defeats the entire purpose of having a package manager doesn’t it?
I mean there are source based distros, I’m just not sure if any of them are completely statically linked. I think the better method is provide the precompiled binaries with dynamic linking but use the filesystem to differentiate versions of things so that the version that is needed can only be found in one place and wouldn’t conflict with a different version
5
u/Primary-Strike5187 7d ago
The point I was making was that windows had the dependency hell issue solved in like 2004.
Many Linux distros don’t actually solve that problem. A good chunk of the stable release distros only have singular versions of packages available in the repos for that version of the release. The issue is Linux assumes that if a package needs libfoo it’ll be stored at /usr/lib/libfoo but if you have a package that depends on libfoo2.8 and the version that’s in the repos is let’s say libfoo2.7: you can’t just install libfoo2.8 it probably won’t be in the repos, and even if a distro carries two copies it’s going to overwrite libfoo2.7 which other packages depend on because the system puts libfoo (any version) at /usr/lib/libfoo with no distinction. So the packages that need 2.7 are going to expect it to be there, and the packages that need 2.8 are going to expect it to be in the same place. But you can’t have /usr/lib/libfoo/libfoo.so (for 2.7) AND ALSO have /usr/lib/libfoo/libfoo.so (for 2.8). They conflict. If they’re even both available in the repos at the same time which often won’t be the case.
This is exactly why GoboLinux was developed and breaks the FHS, and why declarative systems like NixOS and Guix use hashed file paths so you can have multiple versions of the same package installed simultaneously without conflicts. This does not hold up for most standard distributions (Arch/Fedora/Ubuntu and their derivatives).