Greg A. Woods sez:
/*
 * [ On Tue, December 15, 1998 at 09:46:54 (-0500), Todd Vierling wrote: ]
 * > Subject: Package Paths Proposal v2
 * >
 * > 1. /usr is designed to be shared amongst multiple machines of a single
 * >    architecture. Therefore, in the default configuration, files that are not
 * >    exactly the same for all machines of a single archtecture should not go
 * >    here, and files that are written other than at package installation
 * >    should not go here.
 * 
 * There's a subtle mis-conception in there...  /usr isn't designed to be
 * shared amongst multiple machines of a single architecture.  It's
 * designed to be shared (in conjunction with /usr/share) amongst multiple
 * heterogenous machines.

Um..."No".

/usr/share was SPECIFICALLY designed for shareable files; /usr was never
meant to be shared across architectures.  Even places that had /usr/local
"shared" really were exporting /usr/local.$ARCH and using the automounter.

 * 
 * I really wish hier(7) were written to specify /share and /local, not
 * /usr/share and /usr/local.  It would make this little distinction much
 * easier to grasp.

(Pardon the tone of this question -- I'm about to come off as completely
pompous, because there is just no other way to word this, and this is
_not_ my intent.  I have family; I don't need adversaries.)

Just where, perchance, did you intend to keep /share and /local?  You're
implying that they live under root, and you're further implying by extension
that the entire system lives on one big unhappy filesystem.  /share and
/local live under /usr because it's a bigger filesystem.  /usr/local
is more likely to be its own filesystem than is /usr/share, which would
grant /local, but that is (for better or for worse) not the canonical
layout, for aesthetic reasons that I could go into but won't.

 * 
 * (Not that these issues are of much importance any more, except from the
 * point of view of keeping the system layout elegant and hygenic and in
 * making developers think about how to classify the objects they create.)

Precisely.

 * (not to mention the redundant and silly looking "./" prefix in the
 * links! ;-)

Redundant, perhaps; silly, maybe.  Clear?  Yes.  They did it for clarity's
sake.

 * Symlinks are a crutch that should be thrown away at the earliest
 * convenience.

You _did_ grow up under SysV, didn't you? :-)  Seriously, though,
symlinks are a convenience which is not to be abused.  There are times
when they've been necessary (/usr/({include|lib})/X11 -> /usr/X11/$1/X11 under
the standard distribution)

 * 
 * Putting programs, even if you are willing to assume they are scripts,
 * under .../share/ is a *bad* idea.

Do we need a .../share/bin or .../share/scripts directory?  Sharing
scripts across architectures (assuming the same OS :-) is probably
not _un_wise.

 * Put them under $PREFIX/sbin (they *are* meant to be run by hand too!)
 * and put the real daemon binary in $PREFIX/libexec.

THIS make sense, I think...

 * 
 * Mind you, the scripts you outlined contain no really interesting policy
 * decisions and I'd be just as happy to see "start/stop/reload"
 * functionality be built into daemons so long as we're going to stick with
 * the existing functionality of daemon(3) -- it need only be extended a
 * bit to do all this stuff in one common fashion.

What do you mean by that one?  All daemon(3) does is detach and run
in the background.  There are no built-in mechanisms for start/stop/reload
per se (there are canonical guidelines, but nothing is set in stone.
This is, after all, (effectively) UNIX, trademark be damned).  Which,
of course, is why we have the scripts to start/stop/reload.

But, then, you knew that. :-)

 */





				--*greywolf;
--
Q: Where are an elephant's sex organs?
A (rot13): Va uvf srrg.  Vs ur fgrcf ba lbh, lbh'er shpxrq.