Here are two ways of appealing to hier(7)'s apparent authority:

 o hier(7) says that directory Y is for _____, so clearly X does not
   belong in Y.  X belongs in Z.

 o hier(7) says Y is for _____, and Z is for _____.  Since X is
   more Zish than Yish, it belongs in Z.

hier(7) is necessarily incomplete because new types of files have come
into existence since it was written.  hier(7) is also intentionally
incomplete to the extent that it's meant to define a useful set of places
rather than plunking all possible files into their places.

Given hier(7)'s brevity, I argue that it has useful meaning only as a
whole--that the description of every other directory (what doesn't go in
Y) does as much to define what goes in Y as Y's description does.

As a minimum, then, if you really think quoting hier(7) helps, you ought
to compare what hier(7) has to say about the two directories being
discussed rather than leaping forth into argument from only one
directory's description.


As a much more personal opinion, I don't see that the current hier(7)'s
little three-word descriptions do a very good job of defining a useful set
of places.  They don't even explain the very simple difference between
libdata and share.  The example provided by a working system is a far
better learning tool; which is why we're still discussing this trivial
decision, and why I think quoting hier(7) is not helpful.

hier(7) doesn't come close to the level of consideration we're giving this
issue, and doesn't deserve authority over our deliberations.  hier(7)
contains nearly no philosophy--it's a listing of a bunch of files that we
already know where to find.

-- 
Miles Nordin / 1-888-857-2723
555 Bryant Street #182 / Palo Alto, CA 94301-1700