GNU Stow needs a co-maintainer

https://savannah.gnu.org/bugs/index.php?65569

by nequo • 2 years ago

170 115 2 years ago

savannah.gnu.org

freedomben• 2 years ago

I think Savannah is getting an HN hug <3

kstrauser3• 2 years ago

From 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.

Twirrim2• 2 years 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• 2 years ago

Ah, symlink farms, how I love to hate thee! They are alive and well.

tubs• 2 years ago

Still works on link farms, yep. And works pretty well!

RGamma2• 2 years ago

Amazon has an internal Nix/Guix? Probably not much public info on this...

blackeyeblitzar2• 2 years 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• 2 years ago

And so your development environment artifacts can be linked in to the environment root just like any other package (really awesome).

kevin_thibedeau2• 2 years 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.

bandrami• 2 years 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.

colonwqbang• 2 years 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

Perhaps other people have more complex use cases than me.

kstrauser3• 2 years 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.

eternityforest• 2 years ago

I currently use Borg in Vorta to manage my dotfiles. I only have about 5, and half of them have secrets.

I could do it all with shell... but every few likes of custom scripting and config I can ditch is one less thing to worry about, and I don't really need VCS for just a few kb that rarely change.

I've been using a lot more VSCode extensions lately though, so perhaps I'll want to do something for that.

wdfx• 2 years ago

yadm https://yadm.io/ uses git for file management, but also provides some convenience on top of that

kuschkufan• 2 years ago

Can recommend this setup as well, it's great.

hawski• 2 years ago

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

MuffinFlavored• 2 years ago

[flagged]

crest• 2 years ago

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

benced• 2 years ago

Came here to say exactly this

xyst2• 2 years ago

Too soon, bro

shp0ngle• 2 years ago

I'll ping Jigar

rpigab• 2 years ago

  $ stow --list --whatever-options-i-dont-know-it-just-making-a-joke
  ssh -> rsh

BeetleB8• 2 years ago

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.

saghm• 2 years ago

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.

BeetleB8• 2 years ago

Exactly!

mistrial9• 2 years ago

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

Karellen3• 2 years ago

I had a "local" usr/* in my home directory

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.)

BeetleB8• 2 years ago

I always just used `--prefix="$HOME"` so that everything went into `~/bin`, `~/lib`, `~/man`, etc...

Forgive my ignorance, but how do you uninstall stuff a year or two later?

mike_d• 2 years ago

Site is getting hugged to death. Maybe we can update the URL?

They posted the same notice to GitHub: https://github.com/aspiers/stow/issues/104

anacrolix• 2 years ago

It's a trap!

sgammon• 2 years ago

I love Stow!

max_k• 2 years ago

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.

LukeShu• 2 years ago

I want to share a comment I wrote on the 2.1.0 release announcement in 2011: https://news.ycombinator.com/item?id=3309575

tfsh• 2 years ago

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.

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-...

CGamesPlay• 2 years ago

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

malobre2• 2 years ago

Looks great! Seems like GNU Stow inspired many devs, especially around the dotfiles use case

malobre2• 2 years ago

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.

[0] https://brandon.invergo.net/news/2012-05-26-using-gnu-stow-t...

[1] https://github.com/malobre/xdot

OJFord• 2 years ago

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.

throwiforgtnlzy2• 2 years ago

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.

blablabla123• 2 years ago

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)

throwiforgtnlzy2• 2 years ago

Apples (stow) and oranges (containers and exo-package builders and management).

When using commands in conflict with the installed base combined and with things that should run unmodified, it gets tricky, usually in the form of shim binaries or improper PATH manipulation, to run things sufficiently isolated and predictably.

It's cheap enough and reduces the risks for leaking dependencies to create a chroot/jail/cgroup environment that only includes just enough of a standard environment and its specific dependencies rather than allowing unfettered access to all the things at all times.

Depends on what you're doing whether some things can be shoveled in or need more isolation guarantees.

transfire• 2 years ago

Stow never got enough love. Gobo Linux was based on the same idea, it never got enough love.

Now we are paying for it with heavy weight solutions — containers, snaps, flatpak, etc. instead of evolving to a higher-order form of Stow.

grumbel2• 2 years ago

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.

xyst2• 2 years ago

Seems like a zombie project at this point. Maybe a sign that it needs to be put down?

- 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-kid4• 2 years ago

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.

Where do you people keep coming from?

fiddlerwoaroof3• 2 years ago

Perl is not web scale

Dalewyn• 2 years ago

Where do you people keep coming from?

The future.

jjgreen2• 2 years ago

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

HeckFeck2• 2 years ago

At least Perl encourages a culture of documentation.

Getting flashbacks to my job developing Python where I had to learn data structures by literally pausing them in the debugger after starting a big sync job.

No docs, and no pointers as to what is in the dictionary or why... but I'd better close those damn tickets or it's awkward Zoom call time!

johnisgood• 2 years ago

1. What is your issue with Perl with regarding to this project?

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.

citrin_ru2• 2 years ago

1. A fashionable language (e. g. Rust) make it easier to attract new developers, some may contribute just to learn the language. Perl is as unfashionable as it gets for a language still in active use. But if the project don't need a lot of changes / new features it should not matter.

qalmakka2• 2 years ago

written in perl

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.

gwd2• 2 years ago

Resilient, but also infamous for being hard to modify. Our security team has a massive set of automation written in Perl, and it's slowly being replaced, not because it fails, but because the original author left; and when we need to modify it, it's generally easier to rewrite in another language than figure out what it's doing.

Also, you need to manually install all the dependencies on your system before you can use it (whereas "go build" will just go get everything for you); and there are no test cases (whereas "go test" makes it natural to write unit tests as you're developing it, and keep those after whatever feature you're working on is complete). Rust is the same of course. All that adds up to, "More useful to rewrite than to modify".

anticodon• 2 years ago

I use rcm: https://github.com/thoughtbot/rcm

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• 2 years ago

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!).

kazinator7• 2 years ago

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.

kazinator7• 2 years ago

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:

https://www.gnu.org/prep/standards/html_node/DESTDIR.html

tommiegannert• 2 years ago

(Referring to https://www.gnu.org/software/stow/manual/stow.html#Other-FSF...)

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.

kazinator7• 2 years ago

Right. So if the package supports install time prefix with no hassle, it could be done with make DESTDIR=/usr/local/stow/whatever prefix=/ to get rid of the usr/local components. If the prefix override causes a problem, then just live with the extra components. I'm guessing that in that case you tell stow that your package root is at /usr/local/stow/whatever/usr/local. Stow doesn't care about the extra components; your package can be anywhere you like, right?

mid-kid4• 2 years ago

--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.

mossyfog• 2 years ago

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.

TheCleric• 2 years ago

I don't use Stow, but in learning what it was I did see that they did a release two days ago that sounds like it may have fixed your issue:

https://lists.gnu.org/archive/html/info-stow/2024-04/msg0000...

knowsuchagency• 2 years ago

I heard Jia Tan is available

GNU Stow needs a co-maintainer

Related Stories