GNU Stow needs a co-maintainer

Original Article ↗ Hacker News Discussion ↗

GNU Stow, a long-lived Perl tool for managing “symlink farms,” is seeking a co‑maintainer, prompting renewed interest in how it fits into today’s software and dotfile management workflows. Commenters describe using Stow to keep multiple software versions and dotfiles cleanly organized via symlinks, but also note limitations with symlinks, changing practices (containers, Nix/Guix, overlayfs), and the appeal of dedicated dotfile tools like chezmoi, yadm, and rcm. While some argue Stow is essentially “finished” and still uniquely useful, others question its future given its aging ecosystem and more modern, integrated alternatives.

What GNU Stow Does and Typical Use Cases

  • Described as a “symlink farm” manager: install software into versioned directories (e.g., /opt/pkg-1.2.3) and expose them under a common tree via symlinks (e.g., /usr/local).
  • Main benefits:
    • Multiple versions of software without file conflicts.
    • Simple rollbacks and upgrades by switching which directory is stowed.
    • Cleaner uninstalls: remove only symlinks and delete the package directory.
  • Historically used on shared clusters and NFS setups where each machine or user had its own view of /usr/local.
  • Some people use Stow only occasionally now, e.g., for “messy” source installs without uninstall targets.

Dotfiles Management and Alternatives

  • Many commenters use Stow to manage dotfiles by symlinking from a repo tree into $HOME.
  • Others prefer dedicated dotfile tools: chezmoi, yadm, rcm, xdot, dfm, or just “bare git repo” setups.
  • Key reasons to move away from Stow for dotfiles:
    • Symlink-related edge cases and confusion.
    • Desire for templating and per-host configuration.
    • Integrated secret management (e.g., chezmoi with password managers).
  • Some argue plain git works well for single-machine use, but branches become unwieldy for many divergent machines.

Symlinks vs. Modern Approaches (Nix, containers, overlayfs)

  • Several comments note that symlink farms are still used internally at large companies and in research clusters.
  • Critics say symlink-heavy setups can confuse some software and are conceptually superseded by:
    • Nix/Guix (symlink-based but with full package/build systems).
    • Containers, Flatpak, snaps, overlayfs, and “modules” systems.
  • Others counter that Stow remains faster, simpler, and good enough for occasional local use.

Project State, Perl, and Maintainability

  • Some see Stow as “zombie-like” (Perl, low activity, single maintainer, dotfiles repurposing) and suggest it might be time to let it fade in favor of newer tools.
  • Others strongly disagree:
    • The tool is small, stable, and “done”; minimal maintenance is fine.
    • Perl scripts are described as very stable over decades.
    • For this use case, language fashion and web-scale concerns are considered irrelevant.

Technical Notes and Installation Practices

  • Discussion around using --prefix vs. DESTDIR when building from source for use with Stow.
  • DESTDIR is highlighted as the standard for staged installs, though some packages’ prefix handling can complicate usage.
  • Uninstall strategies without Stow include make uninstall, manual tarball-based tracking, or never uninstalling from /usr/local at all.