4 ms·

From https://www.gnu.org/software/stow/ https://www.gnu.org/software/stow/ : "GNU Stow is a symlink farm manager which takes distinct packages of software and/

From https://www.gnu.org/software/stow/ https://www.gnu.org/software/stow/ : "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.

Twirrim 3y ago
>It's pretty nifty. 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.
- thrtythreeforty 3y ago
  Ah, symlink farms, how I love to hate thee! They are alive and well.
  - yjftsjthsd-h 3y ago
    Why do you hate them? (FWIW this is a sincere question; given the number of these things I touch, I would very much like to know if there are problems I need to know about and/or better alternatives)
- tubs 3y ago
  Still works on link farms, yep. And works pretty well!
- RGamma 3y ago
  Amazon has an internal Nix/Guix? Probably not much public info on this...
  - kstrauser 3y ago
    Alternatively, Amazon is using stow, a common GNU utility whose info page refers to a version of Perl released in 1992, or something similar to it, instead of Nix and Guix which didn't exist when Amazon started.
    - fnordpiglet 3y ago
      Which is also the software this submission is about
    - RGamma 3y ago
      Would Amazon rely on stow when it is in this peril? Unless they really do rely on it and maintain an internal fork, which would make this situation even worse. Or they use it anyway...
    - coldtea 3y ago
      It used neither, but it's own implementation of the concept ("symlink all the things!", which is much older than both, and has lots of other implementations too, aside from Nix and Stow. It's how gobolinux works too, for example.
  - paholg 3y ago
    It's not the same. It's been a while, so I'm sure to get things wrong, but you basically had different package groups you could set up. So a service would have its group that it could update, test, and deploy with at once. But like if I produced a package, and another team depended on it, there was no guarantee that the group I ran in CI had versions in common with the group that they deployed. I also remember some weirdness just within one package, like maybe your PR build was based on your local group setup and not anything "official". The coolest thing about it is that you could make a PR against multiple repos at the same time, even if one depended on the other. Like you could add a function to a library in one repo and call it from another repo in one PR.
blackeyeblitzar 3y ago
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?
- jonhohle 3y ago
  And so your development environment artifacts can be linked in to the environment root just like any other package (really awesome).
  - blackeyeblitzar 3y ago
    Sorry I’m not super clear on how this works. Could you explain what it means to be linked in to the environment root?
- kevin_thibedeau 3y ago
  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.
  - kazinator 3y ago
    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.
    - ttyprintk 3y ago
      In the distant past, /usr/local/stow was a NFS mount. Each machine could maintain different symlink trees.
colonwqbang 3y ago
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 https://www.atlassian.com/git/tutorials/dotfiles Perhaps other people have more complex use cases than me.
- kstrauser 3y ago
  There's nothing wrong with that setup. It falls over when you start pushing it across multiple machines with substantial differences. Then Chezmoi's templating is so handy. For example, 99% of my config is the same between my desktop Mac and my various Linux servers, but I use different ssh_config settings on the 2 OSes. Chezmoi makes that very easy. Stock git doesn't. I could script something up to do handle that for me automatically, and before I knew about Chezmoi, that's exactly what I did. Now I'd prefer to let someone else write and maintain all that for me so I can move on to working on other things.
  - markstos 3y ago
    I evaluated Stow and tried Chezmoi for a while but settled on YADM. It’s the bare git repo idea with a little more sugar sprinkled on top. Perfect for my needs.
    - dngray 3y ago
      I switched from Yadm to Chezmoi. The main reason was because there invariably is always something slightly sensitive you don't want in a dotfile and the rest of the file is okay. Yadm uses third party tools to do jinja templating. The first one envtpl stopped being maintained, and the second one j2cli (both jinja2 templaters) aren't very well maintained either. With chezmoi I just use the golang text/template templater. I know it will always be maintained. The integrated password manager functionality for chezmoi also works awesome too. I did initially use stow, but symlinks is just bad. You end up with all sorts of problems with that I can't even remember. My whole dotfiles is 7MB, so if a copy is made from a "source tree" to my home dir that's okay. Chezmoi also encouraged me to do things more deterministically based on hosts and reduce the number of "scripts" that I run significantly, which led to less bugs. I use the same set of dotfiles across a number of my systems.
hawski 3y ago
Is there an overlap of functionality between GNU Stow and OSTree?

Twirrim 3y ago

>It's pretty nifty. 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.

thrtythreeforty 3y ago
Ah, symlink farms, how I love to hate thee! They are alive and well.
- yjftsjthsd-h 3y ago
  Why do you hate them? (FWIW this is a sincere question; given the number of these things I touch, I would very much like to know if there are problems I need to know about and/or better alternatives)
tubs 3y ago
Still works on link farms, yep. And works pretty well!
RGamma 3y ago
Amazon has an internal Nix/Guix? Probably not much public info on this...
- kstrauser 3y ago
  Alternatively, Amazon is using stow, a common GNU utility whose info page refers to a version of Perl released in 1992, or something similar to it, instead of Nix and Guix which didn't exist when Amazon started.
  - fnordpiglet 3y ago
    Which is also the software this submission is about
  - RGamma 3y ago
    Would Amazon rely on stow when it is in this peril? Unless they really do rely on it and maintain an internal fork, which would make this situation even worse. Or they use it anyway...
  - coldtea 3y ago
    It used neither, but it's own implementation of the concept ("symlink all the things!", which is much older than both, and has lots of other implementations too, aside from Nix and Stow. It's how gobolinux works too, for example.
- paholg 3y ago
  It's not the same. It's been a while, so I'm sure to get things wrong, but you basically had different package groups you could set up. So a service would have its group that it could update, test, and deploy with at once. But like if I produced a package, and another team depended on it, there was no guarantee that the group I ran in CI had versions in common with the group that they deployed. I also remember some weirdness just within one package, like maybe your PR build was based on your local group setup and not anything "official". The coolest thing about it is that you could make a PR against multiple repos at the same time, even if one depended on the other. Like you could add a function to a library in one repo and call it from another repo in one PR.

blackeyeblitzar 3y ago

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?

jonhohle 3y ago
And so your development environment artifacts can be linked in to the environment root just like any other package (really awesome).
- blackeyeblitzar 3y ago
  Sorry I’m not super clear on how this works. Could you explain what it means to be linked in to the environment root?
kevin_thibedeau 3y ago
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.
- kazinator 3y ago
  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.
  - ttyprintk 3y ago
    In the distant past, /usr/local/stow was a NFS mount. Each machine could maintain different symlink trees.

colonwqbang 3y ago

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 https://www.atlassian.com/git/tutorials/dotfiles Perhaps other people have more complex use cases than me.

kstrauser 3y ago
There's nothing wrong with that setup. It falls over when you start pushing it across multiple machines with substantial differences. Then Chezmoi's templating is so handy. For example, 99% of my config is the same between my desktop Mac and my various Linux servers, but I use different ssh_config settings on the 2 OSes. Chezmoi makes that very easy. Stock git doesn't. I could script something up to do handle that for me automatically, and before I knew about Chezmoi, that's exactly what I did. Now I'd prefer to let someone else write and maintain all that for me so I can move on to working on other things.
- markstos 3y ago
  I evaluated Stow and tried Chezmoi for a while but settled on YADM. It’s the bare git repo idea with a little more sugar sprinkled on top. Perfect for my needs.
  - dngray 3y ago
    I switched from Yadm to Chezmoi. The main reason was because there invariably is always something slightly sensitive you don't want in a dotfile and the rest of the file is okay. Yadm uses third party tools to do jinja templating. The first one envtpl stopped being maintained, and the second one j2cli (both jinja2 templaters) aren't very well maintained either. With chezmoi I just use the golang text/template templater. I know it will always be maintained. The integrated password manager functionality for chezmoi also works awesome too. I did initially use stow, but symlinks is just bad. You end up with all sorts of problems with that I can't even remember. My whole dotfiles is 7MB, so if a copy is made from a "source tree" to my home dir that's okay. Chezmoi also encouraged me to do things more deterministically based on hosts and reduce the number of "scripts" that I run significantly, which led to less bugs. I use the same set of dotfiles across a number of my systems.

hawski 3y ago

Is there an overlap of functionality between GNU Stow and OSTree?