>> Using the standard install.rb, anything you include in a project's
>> "data"
>> directory will be installed to /usr/share/<package> or equivalent.
>>

[Dave:]
> I have to say I really dislike this: I know it's probably "standard",
> but is ends up spraying files all over the filesystem. It would seem so
> much more sensible to store files under a common subtree, so that
> removing Ruby from a system takes no more than an rm -rf. Having used
> OSX for I while, I guess I'm spoiled, but I'd really much, much rather
> keep the files local to the Ruby tree.

A fine sentiment.  As Mr Herre wrote, Perl provides a precedent for this,
although in that case it's because 'perldoc' always generates its output
from the code.

I dislike seeing 'doc' under a 'lib' directory; they are plainly separate
concerns, but I think there's a whole lot of precedent there (I am by no
means a Unix layout expert).  So that being the case, I want to see 'doc'
put as high in the directory tree as possible, not buried within a
heirachy.

'site_ruby' implies libraries, not documentation.  Not by its name, but by
its contents.  If we were to have 'site_ruby/1.8/docs', then we should
have 'site_ruby/1.8/lib', but we don't.  So rather than force everything
into 'site_ruby', I'd like to see (using $prefix == "/usr")

   /usr/lib/ruby/site_ruby/1.8/  <all sorts of user-installed packages>
   /usr/lib/ruby/1.8/            <standard library>
   /usr/lib/ruby/gems/           <RubyGems; self-contained packages, doc>
   /usr/lib/ruby/doc/ruby-1.8/   <all sorts of "standard Ruby docs">
   /usr/lib/ruby/doc/rake-0.3.1/ <Rake documentation>
   /usr/lib/ruby/doc/dbi-0.0.20/ <DBI documentation>
   /usr/lib/ruby/doc/extmath-0.1.0/ <extmath documentation>
   /usr/lib/ruby/doc/etc.        <etc.>

The philosophy here is that Ruby documentation is a high-enough concern to
warrant a high-level directory, making it easy for the user to browse and
answer the question "what Ruby documentation do I have available?".  Also,
the "dbi-0.0.20" documentation is independent of the *Ruby* version, so it
shouldn't be buried in 'site-ruby/1.8' somewhere.  In this point of view,
Ruby itself is just another unit of Ruby documentation, so "ruby-1.6" and
"ruby-1.8" live alongside "dbi-0.0.20", etc.

All this is meant by way of discussion, by the way.  If we can converge
on, and implement, a standard here, I won't be trying to get in the way. 
I would certainly like to know what people think, however.

Gavin