> Anyway, I think someone should at least *ask* him what was going though his
> mind.  I *have* seen some spool-related executables in "/var" in other
> contexts before; usually something intimately tied to a particular type of
> printer support that usually ends up living under /var/spool/<printername>.
> Although I will say those have usually been shell scripts rather than
> binaries.

As previously noted, the biggest problem with this is that you really
don't want to NFS export /var/spool/whatever to all your clients. In
my case, I have had the following two configs with a server & dataless
client at home ('b)' being the current setup):
	a) client: separate /, /var; shared /usr, /var/obj
	b) client: separate /, /var, /usr; shared /var/obj
(/usr/local, et. al, is under /usr. Also, /var/obj is a separate FS
to /var & /usr/src, and is mounted to the client for when I get pmake
working.)

Also note that at work (a rather *large* workstation cluster & server
environment, with a couple of platforms), we like to keep /usr/local/share
with platform independant files (e.g., man pages) which get mounted
everywhere, and /usr/local/`arch` contains bin, lib, (& conceivably
libdata & libexec), sbin, and X11 dirs to mount as necessary over points
in /usr/local.

Why am I describing this? Because I'm trying to make the point that
application backend binaries in /var are a _bad_ idea; put them in
/usr/local/libexec or sbin where they can be exported as necessary.