As several of you know (I think) the current distribution of scsh
0.6.4 doesn't behave well when one tries to install scsh in a
temporary (aka staging) directory and then move it to its final
destination. To illustrate that, one can issue the following commands
which try to install scsh in /tmp/staging first and then move it to
/tmp/final, using the "standard" trick which passes a different
prefix to "make install":
[lamppc3 ms]% tar xzf scsh-0.6.4.tar.gz
[lamppc3 ms]% cd scsh-0.6.4
[lamppc3 scsh-0.6.4]% ./configure --prefix /tmp/final
[lamppc3 scsh-0.6.4]% make
[lamppc3 scsh-0.6.4]% make install prefix=/tmp/staging
[lamppc3 scsh-0.6.4]% mv /tmp/staging /tmp/final
[lamppc3 scsh-0.6.4]% /tmp/final/bin/scsh
Welcome to scsh 0.6.4 (Olin Shivers)
Type ,? for help.
> ,open pp
Load structure pp (y/n)? y
(open-channel "/tmp/staging/lib/scsh/big/pp.scm" 1)
Apart from the problems related to these hardcoded paths in the scsh
image, another minor problem is that the man page contains incorrect
paths which point to the staging directory.
This problem is known, there are bug reports (with patches) in the
Debian bug-tracking system , and Andreas Voegele submitted a patch
to support something similar recently. Andreas' patch has been
incorporated in the CVS now, but after 0.6.4 was out. I recently got a
bug report for the same thing from a Fink user.
This problem is a bit annoying because it affects packages for Mac OS
(my Fink package has this problem), the Debian package, and all users
who use GNU stow (or a similar program) to install scsh 0.6.4. And it
is even more annoying since sunterlib was released, since sunterlib
As far as I'm concerned, I have a patch for Makefile.in so that the
above sequence of commands work, and I could modify my Fink package to
apply this patch before compiling. But it will only solve the problem
for the Fink package, so it would be cleaner to do a new release of
scsh to solve that issue. But maybe the people in charge of the
distribution feel this is not required, I don't know.
So, to summarise quickly this long mail: should we (scsh package
maintainers) wait for a new release of scsh soon which solves that
problem, or should we work around it using patches?