> It's all a big dump, discoverability is bad.
I see it as easier to discover.
Imagine if you had to goto /usr/bin/output/user to find the whoami binary.
If you did, who is responsible for making those directories and what happens when you have a binary that could really belong in 5 different places?
This is one of the many problems Guix solves on a slightly lower level than most package managers, because binaries live inside Guix packages (/usr/bin is simply populated by absolute symlinks). Of course package managers also do this, but Guix kind of lets you symlink to a (unique) package, rather than `install`.
Re:Why do we need modules at all? (2011)
by johnisgood on Tuesday August 27, 2019 @11:51AM
(#20810960)
For stuff I compile from scratch I just use a symlink-based package manager I found online:
https://zolk3ri.name/cgit/zpkg/
It seems very minimal but supports my requirements. It makes sense to me, because everything gets installed (usually via make install) to ~/.local/pkg/foo-1.0/ and the like, and then symlinks are created to, say, ~/.local/{bin,etc,include,lib,man,share,var}. According to the source code, it is configurable via environment variables. It seems to share similarities with GNU's stow.
Name clauses.
Version clauses. "All binaries inside a folder" needs renames to allow for a different version (even if it's a different minor version).
It's just the binaries, which was OK back in the "program = single binary", before "man" even, days, but now it splits the program from different assets it uses (man pages, default configuration, image assets, etc). This in turn makes deleting/moving more difficult, and adds all kinds of baggage to package managers.
>It's hard to read the list, but Linux has plenty of tools to fix that particular problem.
That's a description of the problem to me. Needing "plenty of tools" to fix an initial bad commitment.