Re: Naming convention for Ruby packages?

[Greg Troxel <gdt%ir.bbn.com@localhost>]

  Ruby modules and gems are ultimately installed into a path that
  depends on the version of Ruby that is installed, e.g. 1.6, 1.8, 1.9,
  etc. Should all Ruby packages have a PKGNAME that starts with
  ${RUBY_PKGPREFIX} (ruby16-, ruby18-, etc.) so that dependencies are
  correct?  The current list of Ruby packages without ${RUBY_PKGPREFIX}
  in the PKGNAME is:

It depends on whether the package is a ruby module (er, gem??) or a
program that happens to be implemented in ruby.

  Several Ruby modules and gems with PKGNAMEs that start with
  ${RUBY_PKGPREFIX} install scripts in ${PREFIX}/bin, which means that
  ruby16-* and ruby18-* versions of these packages will conflict.
  Should we add CONFLICTS lines to the package Makefiles, or should we
  rename the installed binaries by prefixing them with
  ${RUBY_PKGPREFIX}?  The current list of Ruby packages named
  ruby1[68]-* that install scripts in ${PREFIX}/bin is:

This is a tough call; for python we really need coexisting installs, but
the downside is that #!/usr/bin/env python doesn't work, and the rest of
the world expects it to work.

If a package is intended to be used, rather than as a ruby module for
other programs to use, then prefixing seems awkward.  If a package is
intended to be a module and installed as a prereq in multiple ruby
versions, then I think it should have unique names.  Both choices are
icky, so I look at "how often are people going to lose not being able to
install both" vs "how often are people going to lose because programs
ahve the wrong name".

Guile takes a different approach.  1.8 is in /usr/pkg, and 1.6 is in
/usr/pkg/guile/1.6 as a prefix.  I'm not saying it's preferable, but
worth thinkig about.