> This is the first official release of Stow since January 2002

Wait, is this right? The last official release was more than 9 years ago?

Yes, that is right. That's why it's a big deal, and worthy of HN.

Now, the situation would be better if 2.0.x had been released.

Troy Will, the maintainer, had put stow into maintenance mode, and basically stopped after 1.3.3. Kahlil Hodgson did a major rewrite that became Stow 2. The both contributed to it a bit, getting us to 2.0.2.

Stow 2.0.2 was considered stable, and though it could be downloaded from Savannah, Troy felt uncomfortable releasing it officially because he was unfamiliar with the code and felt he couldn't maintain it, or address any problems found. Kahlil wasn't willing to step up as maintainer.

So, 2.1.x marks Adam Spiers becoming involved in the project.

Here is the thread that sparked this: https://lists.gnu.org/archive/html/stow-devel/2011-11/msg000...

(I am the Luke Shumaker quoted in the beginning of the thread. I had an email exchange with Troy about this back in February, but it happened off-list)

That would appear to be correct. See http://www.gnu.org/s/stow, under "Latest news."

I am in the process of getting a plugin installation system working, _right now_. I was going to try to use ZeroInstall.

Y'all think Stow is worth learning about. I like ZeroInstall because it should take care of package dependencies.

I want a 'stow-store'. Something like homebrew for linux. Also the formulas would be written with Python or JSON.

I also long for a deb to stow converted, and Python Package installs.

This is pretty great. Stow (plus git) is how I'm managing the config files for multiple hosts in my respective home dirs, and the conflict resolution switches are going to be a huge help.

I've just been installing applications into ~/base/app_name/app_version using the configure script's --prefix option. Can a Stow user tell me how it is an improvement over my setup?

How do you get at the bin directories? I'm assuming you just add them to your path... Stow basically starts out similarly to what you are doing now--you configure and install to ~/base/stow/xxxx (I usually use app_name-app_version for xxxx but there's no rule). Then you use stow to create a symlink tree in ~/base/{bin,lib,share,etc...}. That way the PATH (and MANPATH, INFOPATH, PERL5LIB, etc.) doesn't have to keep growing for each new app you install. I think that is a nice improvement.

Uninstalling (stow -D) runs through the symlink tree and removes anything from that package.

Thank you very much, I see the advantage now. Handling PATH, LD_LIBRARY_PATH, and the like has been the most annoying part of my setup. It is great to see that Stow can help me out!

That's basically it. I install to ~/local/stow/$pkgname , and run stow -d ~/local/stow $pkgname. Uninstalling is done with rm -rf, upgrading is done by uninstalling then installing. The only $PATH addition is ~/local/bin. A $pkgname-$version scheme might be interesting as well, if I wanted to keep older versions around.

The idea is to simulate that apps are installed in usual places (e.g. /usr/local/).

This sounds like it has similar goals to the Nix package manager. http://nixos.org/nix/

Does it still link to subdirectories instead of files? That was the reason why I switched to graft long ago.

/etc/alternatives competitor?