12 comments
To be fair, I hate package managers in general. ESPECIALLY Homebrew. I don't want packages to have versions because it always inevitably eventually creates a clusterfuck. Just link everything statically ffs. But at least Homebrew doesn't delete packages and indexes from under you. So there's that. Look, I don't want to learn the intricacies of this stuff. I just want to type a package name and have it installed. And I don't want to maintain anything. I want to configure my system once and never touch that again. Is this too much to ask for?! Somehow Maven Central keeps all versions of all packages ever released forever. Even the known-vulnerable log4j versions: So I guess you have to pick which one is more "irresponsible" for you — providing people potentially insecure packages (that might still be fine for their use cases) or breaking their stuff without them touching it. When 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. 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 |
@grishka php 5 ???