On 10/22/07, Marcus Rueckert <[EMAIL PROTECTED]> wrote: > On 2007-10-22 07:17:08 -0400, Trans wrote: > > On 10/22/07, Marcus Rueckert <[EMAIL PROTECTED]> wrote: > > > > > > if debian ships those gems inside the debs, debian becomes the vendor. > > > and debian as a vendor is not supposed to use /opt. the hierarchy is > > > solely for 3rd party vendors. so you could use it for gems installed via > > > the gem cmdline... but in that case /opt feels like the wrong solution. > > > > Right. That's what I mean, for when using gem cmdline. > > > > > i would rather go for /usr/local/lib/ruby/gems/ in that case. > > > > Is that a good place considering someone might install ruby itself to > > /usr/local/lib/? > > there are always disadvantages. but maybe something you want to > consider.
I think you misunderstand me. It is entirely reasonable for someone to install Ruby itself to /usr/local/lib/ruby, if it wasn't for Ruby using a version tier, ie. 1.8/, that would be a complete mess --the gem dir would be mixed in with all the other libs, ostruct.rb, io/, irb/, etc. But even with the tier, I don't think it's a good practice to mixing version tiers with not version tiers --"gems" is not a version of Ruby. Perhaps if the lib/ruby were divided like: T. _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
