On Wed, Jan 22, 2003 at 02:01:25AM +0900, Yukihiro Matsumoto wrote:
> |This is the top directory under which library sources (*.rb) will be installed
> |in subdirectories depending on Ruby version. Files placed in RUBY_LIB_PREFIX directly
> |would be available for all Ruby versions installed on this box and usually
> |they represent the script code which is version-independent.
> 
> *.rb files may or may not be platform independent.  Do you happen to
> know other languages (e.g. perl5) distinguish these directories?
Yes, actually perl5 has this feature (look at 5.8's INSTALL file).
As for platform independancy of *.rb, FHS recommends:

"It is recommended that application-specific, architecture-independent
directories be placed here. Such directories include groff, perl,
ghostscript, texmf, and kbd (Linux) or syscons (BSD). They may, however,
be placed in /usr/lib for backwards compatibility, at the distributor's
discretion. Similarly, a /usr/lib/games hierarchy may be used in addition
to the /usr/share/games hierarchy if the distributor wishes to place some
game data there."
http://www.pathname.com/fhs/2.2/fhs-4.11.html

Also, at the same URL:
"This hierarchy is intended to be shareable among all architecture
platforms of a given OS; thus, for example, a site with i386, Alpha, and
PPC platforms might maintain a single /usr/share directory that is
centrally-mounted. Note, however, that /usr/share is generally not
intended to be shared by different OSes or by different releases of the
same OS.

Any program or package which contains or requires data that doesn't need
to be modified should store that data in /usr/share (or /usr/local/share,
if installed locally). It is recommended that a subdirectory be used in
/usr/share for this purpose. "

So the question is: can you provide examples of *.rb which are not
shareable between different architectures of a concrete OS? Those with
endianess problem in sources could be easily fixed (and they would
probably be fixed anyway).

> 
> |> RUBY_SITE_LIB_PATH2
> |Site-install for non-compiled sources (*.rb) for concrete version of Ruby:
> |RUBY_SITE_LIB_PATH2="${RUBY_SITE_LIB_PATH}/${MAJOR}.${MINOR}"
> |This is Config::CONFIG["sitelibdir"] when VENDOR_SPECIFIC constant isn't
> |defined (or evaluates to false).
> 
> I get it (except the issue above).  Perhaps we need better name though.
The 'VENDOR' part comes from perl5's name of the feature, I tried to
maintain some semantical compatibility. Anyone has a better name?

> 
> |> RUBY_VENDOR_LIB_PATH
> |> RUBY_VENDOR_LIB_PATH2
> |These are produced and used similar to RUBY_LIB_PATH{,2} but for
> |vendor-specific paths for this concrete version of Ruby. They are
> |internally to export RUBY_VENDOR_LIB, RUBY_VENDOR_LIB2.
> |
> |For 1.7 they would be (/usr/share/ruby/vendor_ruby,/usr/lib/ruby/vendor_ruby)
> 
> What 'vendor specific' mean?
A 'vendor-specific' means that packages distributed with OS were built by
this OS vendor and this is used to differentiate the Ruby installation
from that vendor additional Ruby packages as well as local site additions.

So, for example, a ruby interpreter package from distribution will be 
installed into /usr/{lib,share}/ruby/<version> but additional packages
like ruby-dbi or ruby-gettext etc would be installed into
/usr/{lib,share}/ruby/vendor_ruby//<version> and site-specific packages
will go to /usr/local/{lib,share}/ruby/<version>. 

-- 
/ Alexander Bokovoy
---
Nipples, dimples, knuckles, NICKLES, wrinkles, pimples!!