[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-stow] FYI: a couple of stow extensions/alternatives
From: |
Adam Spiers |
Subject: |
Re: [Help-stow] FYI: a couple of stow extensions/alternatives |
Date: |
Tue, 1 Oct 2019 14:52:03 +0100 |
User-agent: |
NeoMutt/20180716 |
On Tue, 1 Oct 2019 at 14:35, Lassi Kortela <address@hidden> wrote:
>Hello,
>
>Just searched for "stow" in FreeBSD ports
>(<https://www.freshports.org/search.php?query=stow>) and it appears
>there are some packages offering extensions and alternatives:
>
>* stowES - Stow enhancement script
>* unstow - Script to unstow packages much faster than stow -D
>* xstow - Enhanced replacement for GNU stow written in C++
>
>I'm not sure whether you know about these already. Might be worth
>looking into them to see if they can be merged into mainline stow.
Thanks a lot for the heads-up; more details below.
>That fast "unstow" package is just a simple shell script:
><https://github.com/knu/stow-utils/blob/master/bin/unstow>. knu is a
>long-time contributor to FreeBSD and a very nice guy in my experience,
>so it would probably be easy to fold this into mainline stow.
Performance enhancements are always very welcome. I've never noticed
unstowing to be particularly slow, so I'm curious why this was
written.
>StowES: <http://os.inf.tu-dresden.de/~adam/stowES/> "automates the
>compilation and installation of software packages by calling tar,
>configure, make, and stow with the appropriate arguments" -- may be a
>bit of an extension to stow's core functionality.
This looks like an effort to turn Stow into a more fully-blown package
manager. Personally I do not believe there is a good future for Stow
in this direction, because there are already several package managers
out there which already do this job very well, e.g. rpm and dpkg.
I've also heard very good things about Nix and GNU Guix but not looked
at them personally.
This is the reason why I changed Stow's web page and manuals to
relabel Stow as a "symlink farm manager", because its scope is clearly
limited to that. That new description encompasses other use cases
for which Stow has been popular for years, such as managing dot files
in user home directories.
Decent package managers need to do far more, such as supporting
reproducible builds, dependency handling, file checksumming, PGP
signatures and other integrity checks, distinguishing config files and
documentation, versioning, upgrades/downgrades, extraction from and
compression to archive formats, ... It's a long list. I don't
personally see value in implementing one or two of these features, but
of course others are welcome to do so.
It's also worth noting that stowES appears to be based on an ancient
1.3.2 version of Stow, and has not been updated since 2013.
>XStow: <http://xstow.sourceforge.net/>. It "supports all features of
>Stow with some extensions" but the says last release was in 2014 so that
>claim is probably not true anymore. As expected, the motivation for
>XStow was: "Stow requires Perl. But what's on systems where no Perl is
>available, or not yet installed? I tried compiling Stow with perlcc, but
>it failed. For compiling XStow a C++ compiler and a system with a couple
>of POSIX functions is required. It does not depend on an interpreter.
>Static compilation e.g. for rescue disks is possible."
Regarding XStow I think I can just link to what I previously wrote in
2013:
https://unix.stackexchange.com/questions/73461/differences-between-xstow-and-stow