OK, I'm mad.  In both senses.  

Am I the only person who thinks it's no fun to guess which rock pkg_add
hid the documentation for <packagename>?  Let's see:

/usr/pkg/share/<pkg>
/usr/pkg/share/doc/<pkg>
/usr/pkg/share/doc/html/<pkg>
/usr/X11R6/share/<pkg>
/usr/X11R6/share/doc/<pkg>
/usr/X11R6/share/games/<pkg>

I'm probably missing some, but that's not the point.  What I want to know
is, why on earth would any package's documentation be anywhere except
/usr/pkg/share/?

I'd like to bring some rationality to this, starting with hier(7), so
we're all on the same page, so to speak.  Then I want to patch every last
package so it will DTRT once and for all.  I don't know exactly how to do
that, but I'm pretty sure once I've fixed one package, I'll know how to
fix most of them.  But there's no sense aiming at a moving target: we have
to agree on what we want.  

I'm pretty sure it takes both kinds of madness to attempt such a thing.  

My suggestion is that /usr/pkg/share hold the documentation in a tree
mimicking /usr/pkgsrc.  IOW, 

instead of 
	/usr/pkg/share/doc/html/ghostscript
we have 
	/usr/pkg/share/print/ghostscript

and instead of 
	/usr/X11R6/share/doc/vnc
we have 
	/usr/pkg/share/net/vnc

Of course, /usr/pkg/info is useful and should be kept.  And mentioned in
hier(7).  

One tree to hold the docs, one search to find them.  Less darkness, more
light, say I.  
Can we do this?  

--jkl