3 ms·

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 v

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.
    - JeremyNT 3y ago
      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. For this though, "modules" is still around [0] [0] https://modules.sourceforge.net/ https://modules.sourceforge.net/
  - BeetleB 3y ago
    Curious: How do you uninstall stuff you manually installed in /usr/local?
    - kazinator 3y ago
      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.
      - BeetleB 3y ago
        > 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. No need for "make uninstall", etc.
        deleted 3y ago
        [deleted]
        deleted 3y ago
        [deleted]
        3y ago
  - kevin_thibedeau 3y ago
    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.
bandrami 3y ago
You install libfoo 4.7 to /usr/local/stow/libfoo-4.7 (such that you have /usr/local/stow/libfoo-4.7/bin/foocfg and /usr/local/stow/libfoo-4.7/lib/libfoo-4.7.0.so and /usr/local/libfoo-4.7/share/man/man1/foocfg.1.gz), and then libfoo 4.8 to /usr/local/stow/libfoo-4.8. Then from /usr/local/stow you run `stow libfoo-4.7` and all the contents mentioned above are symlinked into /usr/local appropriately. Then if you want to switch libraries you unstow that one and stow version 4.8. It's highly configurable, so you can do a lot more with it than that, but that was the idea behind it 25 years ago. There were whole distros based on that, though it fell out of favor when containers became a bigger thing in the late oughts.

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.
  - JeremyNT 3y ago
    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. For this though, "modules" is still around [0] [0] https://modules.sourceforge.net/ https://modules.sourceforge.net/
- BeetleB 3y ago
  Curious: How do you uninstall stuff you manually installed in /usr/local?
  - kazinator 3y ago
    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.
    - BeetleB 3y ago
      > 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. No need for "make uninstall", etc.
      - deleted 3y ago
        [deleted]
      - deleted 3y ago
        [deleted]
      - 3y ago
- kevin_thibedeau 3y ago
  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.

bandrami 3y ago

You install libfoo 4.7 to /usr/local/stow/libfoo-4.7 (such that you have /usr/local/stow/libfoo-4.7/bin/foocfg and /usr/local/stow/libfoo-4.7/lib/libfoo-4.7.0.so and /usr/local/libfoo-4.7/share/man/man1/foocfg.1.gz), and then libfoo 4.8 to /usr/local/stow/libfoo-4.8. Then from /usr/local/stow you run `stow libfoo-4.7` and all the contents mentioned above are symlinked into /usr/local appropriately. Then if you want to switch libraries you unstow that one and stow version 4.8. It's highly configurable, so you can do a lot more with it than that, but that was the idea behind it 25 years ago. There were whole distros based on that, though it fell out of favor when containers became a bigger thing in the late oughts.