>>>>> "Anthony" == Anthony Towns <aj@azure.humbug.org.au> writes:
>> /usr/local/stow
Anthony> Package: stow Description: Organiser for /usr/local/
Anthony> hierarchy GNU Stow helps the system administrator
Anthony> organise files under /usr/local/ by allowing each piece
Anthony> of software to be installed in its own tree under
Anthony> /usr/local/stow/, and then using symlinks to create the
Anthony> illusion that all the software is installed in the same
Anthony> place.
I suspect people don't understand the problems that the current policy
has on stow. Just in case, I will spell it out:
stow allows you to install packages under
/usr/local/stow/package/*
For instance, I might have
/usr/local/stow/flightgear-0.0/bin
/usr/local/stow/flightgear-0.0/lib
/usr/local/stow/flightgear-0.0/man
(actually I have never installed flightgear, so don't know what
directory structure it uses, but am considering it. I don't think any
debian package exists. Also, I am making up the version number, 0.0)
In the /usr/local/stow directory, I would type in
stow flightglear-0.0
this would create the following symlinks (assuming the directories
don't already exist):
/usr/local/bin ---> /usr/local/stow/flightgear-0.0/bin
/usr/local/lib ---> /usr/local/stow/flightgear-0.0/lib
/usr/local/man ---> /usr/local/stow/flightgear-0.0/man
Then I install xemacs. This would (I think, haven't double checked
this though) create the following directory:
/usr/local/lib/xemacs/site-lisp
After a while, I might want to add files here, eg mailcrypt so I can
use gpg with gnus (current Debian versions of mailcrypt that support
gpg do not compile for xemacs20). So the obvious thing would be just
to put them in the already created directory, ie
/usr/local/lib/xemacs/site-lisp/mailcrypt.el
So why is this dead wrong?
The directory went in the wrong place. Instead of the above location,
it really went here:
/usr/local/stow/flightgear-0.0/lib/xemacs/site-lisp/mailcrypt.el
After I while, I get fed up with flightgear and want to delete
it (eg perhaps a Debian version is out by then). So I type:
rm -rf /usr/local/stow/flightgear-0.0
and delete my lisp files at the same time.
While, yes, I did make a mistake it using existing directory, I think
the real problem is that the directory went in the wrong spot in the
first place. flightgear doesn't have anything to do with lisp (AFAIK),
so having a /usr/local/stow/flightgear-0.0/lib/xemacs/site-lisp
directory is completely wrong.
However, I would be happy with the proposal to make this a config
option. If however, it is judged that this is too complicated (I doubt
it), then I would prefer policy specify a file, eg
/usr/share/doc/package/local that documents all local directories that
the system administrator may use for the package. Then again, I would
like this anyway.
eg one line for directory:
/usr/local/lib/xemacs/site-lisp local lisp files
so a system administrator could find all packages that use
/usr/local/lib by a simple grep (or egrep) command.
(not tested)
egrep '^/usr/local/lib' /usr/share/doc/*/local
which IMHO is far more useful then the current mechanism anyway.
There are probably one million plus one ways to enhance on the above
command.
--
Brian May <[EMAIL PROTECTED]>
