"GNU Stow is a symlink farm manager which takes distinct packages of software and/or data located in separate directories on the filesystem, and makes them appear to be installed in the same place."
The idea is that instead of installing package foopkg directly into /usr/local, you could install it to /opt/foopkg-v1.2.3. Then you can run stow to make a bunch of symlinks like /usr/local/bin/foo -> /opt/foopkg-v1.2.3/bin/foo. Upgrade it to a new version, re-run stow, and now all the symlinks point to /opt/foopkg-v4.5.6/bin/foo and so on. It's pretty nifty.
However, I used it more for managing dotfiles in my home directory than anything else, making links like ~/.vimrc -> ~/src/my-config-repo/.vimrc . I much prefer using chezmoi for that now.
I've found that stock git works great for managing dotfiles, without any extra tools needed. Just a few lines of gitconfig and a shell alias is enough. It's all explained here: https://www.atlassian.com/git/tutorials/dotfiles
Perhaps other people have more complex use cases than me.
It's how Amazon's stuff used to work (though not using Stow) back several years ago. No idea if they've migrated from that approach to containers, or similar, yet.
Every application you deployed would have the necessary components deployed (or re-used if you had something else that already used it), and then build the application space from symlinks to those parts. Worked really well.
What is the use case for this? Is the idea that it can automatically turn a package into a portable package, effectively? Or is it so you can install multiple versions of the same software without conflict between them?
I've been using Stow for about two years now to manage my dotfiles. In order to improve the UX I've wrapped it within a small utility which allows me to define packages (directories of dotfiles that should be managed) such as zsh (containing .zshrc, .zshenv, .zlogin, etc) and their respective locations [1]. There's a few other niceties such as modular Zsh file sourcing, allowing encapsulation by OS, automatic git-crypt support, and dependency resolution across mac and debian.
I've been tempted to try NixOS due to its emphasis on config-as-code, but this isn't something I can feasibly do as this would fragment my dotfiles across different ways of thinking, which conflicts with my desire to have one repo for every device. Which I've achieved pretty successfully as these dotfiles exist on my personal/work macs, WSL, work/personal linux workstations and a few colleagues devices. All of which works out of the box with a single $ git clone and invocation of a bootstrap.zsh file which installs and sources everything you'd need.
The real magic behind all of this is Stow, so I'll always be eternally grateful to its maintainers. If I wasn't a complete stranger to the GNU ecosystem, I'd step up and offer my help.
The GNU Stow documentation has a curious blind spot; it doesn't mention the DESTDIR convention for installing in a separate directory:
$ ./configure --prefix=/usr/local
$ make
$ make install DESTDIR=/usr/local/stow/whatever
Using "make prefix=..." is not the main mechanism for overriding the install location; DESTDIR is. DESTDIR is widely supported, and documented in the GNU Coding Standards, in the Makefile Conventions section of the Release Process chapter:
They serve two different purposes. DESTDIR places files in a staging directory, e.g. to be packaged into a tarball.
In your example, you will end up with the program at /usr/local/stow/whatever/usr/local/bin, which I'm guessing Stow is trying to avoid, because it's ugly and the extra directories are unnecessary. Not wrong, though. With their approach, it ends up at /usr/local/stow/whatever/bin.
--prefix= exists to configure the install location, and you shouldn't use any other mechanism for that.
DESTDIR exists to add another prefix on top of what --prefix= specifies, for the purpose of temporarily copying the program into, for example for packaging. A lot of programs will not run from their DESTDIR location, and they must be copied out of DESTDIR to run.
For example, --prefix=/foo DESTDIR=/bar will install into /bar/foo, but running /bar/foo/bin/prog will not function properly, until you "mv /bar/foo /foo" and run it as /foo/bin/prog. There's a very limited set of programs that will try to figure out their prefix at runtime, by checking the location of the binary, but this is hard to do properly and comes with caveats, and the programs that support this are few and far between.
Poor stow. We used it in the stone age about 20 years ago for unpackaged, shared software management on academic research clusters (Think "/usr/{{other hierarchy}}" over NFS). The problem with it is it depends entirely on symlinks and some programs get confused or just don't like them.
Nix, hab/habitat, containers, or overlay filesystems (such as with flatpak, etc.) are options that might work better that get around this problem.
I used to use it quite a lot actually. Nowadays maybe twice a year if I need to install a messy source dependency cleanly. For such rare usages symlink handling is quite a non-issue. When I used it so intensively, actually I mostly used xstow which can automatically resolve common conflicting symlinks on directories, unfortunately that's not maintained anymore.
(Sure, there's Nix and containers but stow is way faster)
I used Stow (some years ago) until I discovered the XDG directory spec. It can be a bit more painful on macOS, but generally enough respects it that it makes more sense to me to use it by default and fix/carve workarounds for what doesn't than to use tools like Stow to essentially put everything in the latter category.
That said, I don't imagine it was built for 'dotfiles' as everyone is and will discuss it being used for, so perhaps it does deserve to live on.
Nix and Guix do pretty much that, at the core they are just some symlinks and environment variables. But unlike stow, they build all the rest of the package management and build infrastructure as well.
The big issue with stow is that you have to manually get the packages into DESTDIR and quite a lot of packages don't directly support that or do it in their own non-standard way, so there is far too much manual work involved getting anything installed from source. With Nix and Guix you can write a package definition once and than everybody can reuse that instead of reinventing the wheel.
A few years ago I read a blog post [0] on using GNU Stow to manage your dotfiles, I loved the idea and it inspired me to create xdot, a minimalist dotfiles manager [1] which I have been using ever since.
stow was a really useful tool for me once at work. I had a "local" usr/* in my home directory for custom packages I'd install. Occasionally I'd need to swap different versions of the same library, etc. stow made the process a lot more manageable.
I've found it useful occasionally for when I've needed to install something via source that didn't include an "uninstall" target in their build configuration. Being able to "unstow" all of the symlinks will clean up all of the system directories, at which point you can just delete the entire folder where the actual installation occurred if you don't want to keep it around at all.
I always just used `--prefix="$HOME"` so that everything went into `~/bin`, `~/lib`, `~/man`, etc...
I did look into stow a couple of times, and would have been fine with it dropping symlinks going into those dirs if I'd have used it.
(A few years after XDG started being commonly used I moved everything in my `~/etc` into `~/.config`, and `~/etc` is now a symlink to it. I occasionally wonder if doing it the other way around and setting up XDG_CONFIG_DIR would be more old-skool, before catching my reflection in my monitor and realising how daft that thought is.)
I saw a german after-midnight guy setup postgresql like this once, on linux.. rather quickly ;-) All the significant system parts were in an alternate LD_LIBRARY_PATH plus the postgresl libs
It's a simple tool with no dependencies besides perl (which will be around forever) and no cybersecurity footprint. Even if it were to be abandoned for a decade it would still work fine and serve a purpose. There also exists no better alternative for symlink-farm style management.
I used to do quite a bit of Perl, and occasionally have need to run scripts which are 10, 15 years old -- I can't remember a case where one of those didn't work. A two-month old Python script, that's 50/50
Perl scripts are surprisingly resilient. I have seen Python modules only a handful years old turning to garbage, and unmaintained Perl modules still working fine after > 20 years.
It is very simple and easy to use, has no external dependencies, and is sufficiently flexible to handle configurations for different machines and other nifty features.
I'm aware of Nix and other solutions, but you can start using rcm in 10 minutes (it's really that easy to use). If you choose Nix, for example, you'll need to spend at least several weeks of time (guessing on experience of others).
> If you choose Nix, for example, you'll need to spend at least several weeks of time (guessing on experience of others).
If you have no prior Nix experience, probably. Home Manager isn't really hard to work with, but its docs do assume basic Nixlang and Nix module system knowledge. If you try to cargo cult your way directly into a working flake with HM, you'll probably get a little lost.
But you also don't have to jump in all at once. I used a separate dotfile manager in conjunction with Nix for years, and it worked great. (I only bothered to switch to HM because the tool I was using became unmaintained! I was perfectly happy with it.) You can definitely ease into managing your dotfiles with Nix so it doesn't impose any downtime on you.
Using rcm for dotfiles plus Nix for the packages you regularly install is a pretty good idea imo. Then you can transition to using HM for dotfiles management later (or never!).
I think you can merge multiple directories onto /usr/local using overlayfs.
That seems to be what Stow is simulating, using symlinks.
Symlinks have the advantage that they persist; you don't have to recreate them after every reboot.
Stow also has ignore lists, which isn't something overlayfs will do, or not nicely; it is oriented toward directories. In the package installation use case, you could just keep unwanted cruft out of the individual installation directories that are being combined.
I use stow as a dotfile manager. works great!
only problem is that there are some weird bugs.
For example it would get confused when I had a `.fonts/` symlink in my home.
Also, the "dot-" prefix really should be a built-in thing and not a fork.
But maybe stow wasn't made for this, maybe someone should reinvent stow with dotfiels in mind.
And no chezmoi doesn't count.
I evaluated Stow for dotfiles, but I wanted something simpler to deploy (single binary). I built a solution myself several years ago, which shares many features with Stow, and it’s still kicking along. https://github.com/cgamesplay/dfm
Me too! I've been using it for 20 or so years, and it's one of those pieces I didn't know it was still developed or what features were added, because the feature set from 20 years ago is still enough for me. IOW: maybe it doesn't need a maintainer at all.
Give him some time to recover first. After all the haters destroyed the fruits of his tireless labour of love to which he dedicated years of his life. /s
[+] [-] kstrauser|1 year ago|reply
"GNU Stow is a symlink farm manager which takes distinct packages of software and/or data located in separate directories on the filesystem, and makes them appear to be installed in the same place."
The idea is that instead of installing package foopkg directly into /usr/local, you could install it to /opt/foopkg-v1.2.3. Then you can run stow to make a bunch of symlinks like /usr/local/bin/foo -> /opt/foopkg-v1.2.3/bin/foo. Upgrade it to a new version, re-run stow, and now all the symlinks point to /opt/foopkg-v4.5.6/bin/foo and so on. It's pretty nifty.
However, I used it more for managing dotfiles in my home directory than anything else, making links like ~/.vimrc -> ~/src/my-config-repo/.vimrc . I much prefer using chezmoi for that now.
[+] [-] colonwqbang|1 year ago|reply
Perhaps other people have more complex use cases than me.
[+] [-] Twirrim|1 year ago|reply
It's how Amazon's stuff used to work (though not using Stow) back several years ago. No idea if they've migrated from that approach to containers, or similar, yet.
Every application you deployed would have the necessary components deployed (or re-used if you had something else that already used it), and then build the application space from symlinks to those parts. Worked really well.
[+] [-] blackeyeblitzar|1 year ago|reply
[+] [-] hawski|1 year ago|reply
[+] [-] tfsh|1 year ago|reply
I've been tempted to try NixOS due to its emphasis on config-as-code, but this isn't something I can feasibly do as this would fragment my dotfiles across different ways of thinking, which conflicts with my desire to have one repo for every device. Which I've achieved pretty successfully as these dotfiles exist on my personal/work macs, WSL, work/personal linux workstations and a few colleagues devices. All of which works out of the box with a single $ git clone and invocation of a bootstrap.zsh file which installs and sources everything you'd need.
The real magic behind all of this is Stow, so I'll always be eternally grateful to its maintainers. If I wasn't a complete stranger to the GNU ecosystem, I'd step up and offer my help.
For anyone who's curious here's my dotfiles: https://github.com/o-y/dotfiles
1: https://github.com/o-y/dotfiles/blob/main/bootstrap.zsh#L38-...
[+] [-] kazinator|1 year ago|reply
https://www.gnu.org/prep/standards/html_node/DESTDIR.html
[+] [-] tommiegannert|1 year ago|reply
They serve two different purposes. DESTDIR places files in a staging directory, e.g. to be packaged into a tarball.
In your example, you will end up with the program at /usr/local/stow/whatever/usr/local/bin, which I'm guessing Stow is trying to avoid, because it's ugly and the extra directories are unnecessary. Not wrong, though. With their approach, it ends up at /usr/local/stow/whatever/bin.
[+] [-] mid-kid|1 year ago|reply
DESTDIR exists to add another prefix on top of what --prefix= specifies, for the purpose of temporarily copying the program into, for example for packaging. A lot of programs will not run from their DESTDIR location, and they must be copied out of DESTDIR to run.
For example, --prefix=/foo DESTDIR=/bar will install into /bar/foo, but running /bar/foo/bin/prog will not function properly, until you "mv /bar/foo /foo" and run it as /foo/bin/prog. There's a very limited set of programs that will try to figure out their prefix at runtime, by checking the location of the binary, but this is hard to do properly and comes with caveats, and the programs that support this are few and far between.
[+] [-] throwiforgtnlzy|1 year ago|reply
Nix, hab/habitat, containers, or overlay filesystems (such as with flatpak, etc.) are options that might work better that get around this problem.
[+] [-] blablabla123|1 year ago|reply
(Sure, there's Nix and containers but stow is way faster)
[+] [-] OJFord|1 year ago|reply
That said, I don't imagine it was built for 'dotfiles' as everyone is and will discuss it being used for, so perhaps it does deserve to live on.
[+] [-] mike_d|1 year ago|reply
They posted the same notice to GitHub: https://github.com/aspiers/stow/issues/104
[+] [-] transfire|1 year ago|reply
Now we are paying for it with heavy weight solutions — containers, snaps, flatpak, etc. instead of evolving to a higher-order form of Stow.
[+] [-] grumbel|1 year ago|reply
The big issue with stow is that you have to manually get the packages into DESTDIR and quite a lot of packages don't directly support that or do it in their own non-standard way, so there is far too much manual work involved getting anything installed from source. With Nix and Guix you can write a package definition once and than everybody can reuse that instead of reinventing the wheel.
[+] [-] malobre|1 year ago|reply
[0]: https://brandon.invergo.net/news/2012-05-26-using-gnu-stow-t...
[1]: https://github.com/malobre/xdot
[+] [-] BeetleB|1 year ago|reply
[+] [-] saghm|1 year ago|reply
[+] [-] Karellen|1 year ago|reply
I always just used `--prefix="$HOME"` so that everything went into `~/bin`, `~/lib`, `~/man`, etc...
I did look into stow a couple of times, and would have been fine with it dropping symlinks going into those dirs if I'd have used it.
(A few years after XDG started being commonly used I moved everything in my `~/etc` into `~/.config`, and `~/etc` is now a symlink to it. I occasionally wonder if doing it the other way around and setting up XDG_CONFIG_DIR would be more old-skool, before catching my reflection in my monitor and realising how daft that thought is.)
[+] [-] mistrial9|1 year ago|reply
[+] [-] xyst|1 year ago|reply
- written in perl
- 1 maintainer
- not much activity on GH or mailing lists
- pivot from initial purpose as “symlink farm” to dot file management
It’s had a nice run but seems much better alternatives exist now (as mentioned in comments)
[+] [-] mid-kid|1 year ago|reply
Where do you people keep coming from?
[+] [-] jjgreen|1 year ago|reply
[+] [-] qalmakka|1 year ago|reply
Perl scripts are surprisingly resilient. I have seen Python modules only a handful years old turning to garbage, and unmaintained Perl modules still working fine after > 20 years.
[+] [-] johnisgood|1 year ago|reply
2. Is the project not more or less complete?
3. See above.
4. What exactly is the issue?
As for alternatives, I do not see any mentioned. I did hear about https://zolk3ri.name/cgit/zpkg/ though.
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] freedomben|1 year ago|reply
[+] [-] anticodon|1 year ago|reply
It is very simple and easy to use, has no external dependencies, and is sufficiently flexible to handle configurations for different machines and other nifty features.
I'm aware of Nix and other solutions, but you can start using rcm in 10 minutes (it's really that easy to use). If you choose Nix, for example, you'll need to spend at least several weeks of time (guessing on experience of others).
[+] [-] pxc|1 year ago|reply
If you have no prior Nix experience, probably. Home Manager isn't really hard to work with, but its docs do assume basic Nixlang and Nix module system knowledge. If you try to cargo cult your way directly into a working flake with HM, you'll probably get a little lost.
But you also don't have to jump in all at once. I used a separate dotfile manager in conjunction with Nix for years, and it worked great. (I only bothered to switch to HM because the tool I was using became unmaintained! I was perfectly happy with it.) You can definitely ease into managing your dotfiles with Nix so it doesn't impose any downtime on you.
Using rcm for dotfiles plus Nix for the packages you regularly install is a pretty good idea imo. Then you can transition to using HM for dotfiles management later (or never!).
[+] [-] kazinator|1 year ago|reply
That seems to be what Stow is simulating, using symlinks.
Symlinks have the advantage that they persist; you don't have to recreate them after every reboot.
Stow also has ignore lists, which isn't something overlayfs will do, or not nicely; it is oriented toward directories. In the package installation use case, you could just keep unwanted cruft out of the individual installation directories that are being combined.
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] mossyfog|1 year ago|reply
But maybe stow wasn't made for this, maybe someone should reinvent stow with dotfiels in mind. And no chezmoi doesn't count.
[+] [-] TheCleric|1 year ago|reply
https://lists.gnu.org/archive/html/info-stow/2024-04/msg0000...
[+] [-] CGamesPlay|1 year ago|reply
[+] [-] malobre|1 year ago|reply
[+] [-] knowsuchagency|1 year ago|reply
[+] [-] anacrolix|1 year ago|reply
[+] [-] sgammon|1 year ago|reply
[+] [-] max_k|1 year ago|reply
[+] [-] MuffinFlavored|1 year ago|reply
[+] [-] shp0ngle|1 year ago|reply
[+] [-] rpigab|1 year ago|reply
[+] [-] benced|1 year ago|reply
[+] [-] crest|1 year ago|reply
[+] [-] unknown|1 year ago|reply
[deleted]
[+] [-] xyst|1 year ago|reply