Gregory's ServerWhen I was describing my proposed solution to package management in one chat where people complain about computers — no absolute paths, no dependency hell, no intermingling files from different sources, Java-classpath-like $PATH/includes/libs environments — I was told that I'm trying to reinvent Nix. And indeed it looks like what I want. I need to try it sometime.
|
5 comments
 Okay so digging deeper into it, Nix does use absolute paths for libraries, but they point to the correct version of the installed library within the "Nix store". So it's not quite like Java classpaths. But this is still fine as far as avoiding version conflicts goes. It still allows you to have multiple versions of the same library installed at once. The only place where there can be a "default" version of a package is a user/shell environment for packages that provide executables. Makes sense.  Not sure about Nix, but usually versioning is done with sonames. Like libbullshit.so.1 and libbullshit.so.2, which are resolved into different versions. And why absolute paths? This makes no sense. @uis yes, but usually those library packages would also include: So in the end, you can't have multiple versions side-by-side, so if you want to install a package that needs a newer version of this library, you also have to upgrade its dependents you installed earlier. [Part 1] - usualy cflags for library are obtained through pkg-config, which includes headers search location, so headers can be located anywhere and be versioned. As long as config is versioned. Although usually includes(-dev packages, if talking in debianisms) are installed unversioned for "default" version |
No absolute paths and no relative paths?
What you define as "dependency hell"?