It lets you have informal package management of self-compiled binaries in parallel with your distro's package manager. With Stow you can install updated libs and applications into /usr/local and don't have to be concerned with conflicts. At worst you may need to set LD_PRELOAD to bypass system libs. Very useful with Debian stable when you need a new feature in something and don't want to wrestle with backports.
I've never had a problem installing self-compiled stuff into /usr/local without conflicts. I'd have to have the problem of installing multiple versions (upgrades) and needing to be able to roll back easily, along with any config files and such.
The problem is when you want to uninstall things. With Stow you don't have to track down the installer droppings scattered everywhere. The nice part of Stow is that it builds minimal symlinks and converts them to a deeper hierarchy once a second package wants to use a common directory.
And this sort of thing is still common in large shared research computing clusters, where stuff gets installed in arbitrary locations and old libraries with obscure build dependencies are the norm.
I mostly use nix with direnv so I never have to install anything globally and, between overrides and a minimal understanding of how to write a custom package, it’s surprisingly easy to get the tools you need for each project.
Anything I install in /usr/local is stuff is going to be something I really need, and for which there isn't a distro package. It stays for the life of the system.
If I wanted to install something into /usr/local that would be suspected of needing removal later, I'd build it with /usr/local as a prefix, but install it in a temporary directory, then make a tarball package out of that to keep track of the file list. That could be used to remove it. I could trivially generate an uninstall script by using find in the package directory to get a list of relative paths; converting each to a rm command. The uninstall script would be put into /usr/local and run from there.
> If I wanted to install something into /usr/local that would be suspected of needing removal later, I'd build it with /usr/local as a prefix, but install it in a temporary directory, then make a tarball package out of that to keep track of the file list. That could be used to remove it. I could trivially generate an uninstall script by using find in the package directory to get a list of relative paths; converting each to a rm command. The uninstall script would be put into /usr/local and run from there.
Compared to using stow, this is two orders of magnitude more complicated :-) With stow, you simply install it anywhere, and stow will make the symlinks into /usr for you. When you want to uninstall it, stow will remove all the symlinks. This way, I would install each package into its own directory. When I want to remove it, I use stow to delete all the symlinks, and then just delete the directory.
It's only theoretical; I've never uninstalled anything out of a /usr/local.
What Stow is doing, by the way, is better achieved with overlayfs, which didn't exist when Stow was first introduced.
With overlayfs you can specify multiple directories that are merged together. Multiple packages that are rooted at /usr/local can be mapped there with overlayfs.
