Re: /usr/local policy

[Brian May <bam@debian.org>]

>>>>> "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 <bam@debian.org>