Re: FYI: a couple of stow extensions/alternatives

On Tue, 1 Oct 2019 at 14:35, Lassi Kortela <[email protected]> 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