Refusal to handle entries that are absolute symlinks is a regression in some workflows

[callegar]

The most recent version of GNU stow errors out when some entry is an absolute symlink. For instance you may get:

WARNING! stowing MATLAB_2025a would cause conflicts:
  * source is an absolute symlink stow/MATLAB_2025a/bin/matlab => /opt/MATLAB/R2025a/bin/matlab
  * source is an absolute symlink stow/MATLAB_2025a/bin/mex => /opt/MATLAB/R2025a/bin/mex
All operations aborted.

Previous versions of GNU stow would deal with this just fine, without aborting.

While the checks introduced in the most current version can be useful in many cases, they represent a showstopper in other workflows. I think that a command line option is needed to turn this error into a warning and proceed as the older stow versions used to do.

The example above shows a case where this is useful.

When you install MATLAB, it typically goes in its own directory, so that the executables remain out of your path. To make it easier to invoke the program, it asks you if you want the main executables to be symlinked to some location on your path (proposing /usr/local/bin). What I like to do is to tell MATLAB to put these executables in /usr/local/stow/MATLAB_XXXXy/bin where XXXXy is the MATLAB version (e.g., 2024b). Then I stow MATLAB_XXXXy. This is quite nice, because multiple MATLAB versions can be installed side to side and with the stow trick I can quickly change which version gets run by writing matlab (and I can also be sure that the version of mex matching the current MATLAB is selected.

Similar pieces of software work in a similar way. Now this has become impossible to manage with the latest version of stow.