On Nov 27, 2007 8:40 PM, Mauricio Fernandez <[EMAIL PROTECTED]> wrote: > I haven't experienced this directly, but the code is quite clear. > I had to take a look at lib/rubygems.rb after receiving bug reports for > FastRI+Leopard and found: > > Index: lib/rubygems.rb > =================================================================== > --- lib/rubygems.rb (revision 1493) > +++ lib/rubygems.rb (revision 1498) > [...] > @@ -519,7 +522,7 @@ > # not specified in the environment. > def default_dir > if defined? RUBY_FRAMEWORK_VERSION > - return File.join(File.dirname(Config::CONFIG["sitedir"]), "Gems") > + return File.join(File.dirname(Config::CONFIG["sitedir"]), "Gems", > Config::CONFIG['ruby_version']) > else > File.join(Config::CONFIG['libdir'], 'ruby', 'gems', > Config::CONFIG['ruby_version']) > end > > It seems that doing gem update --system will lose all your gems. >
Actually no, this code path wasn't used until Leopard provided a version of Ruby distributed as a framework. The version of RubyGems that ships by default in Leopard has this change too. Upgrading RubyGems gem should not break anything in Leopard. > PS: is such vendor/repackager-specific patching encouraged? In other words, > would it be acceptable to have FreeBSD, Debian, Gentoo and friends add a > number of if defined? __SOME_PLATFORM_ID__ ...? If they were all allowed to > do what Apple did (provide patches to be applied by the RubyGems developers), > they would be able to solve problems like those discussed in ruby-talk > recently. Until a better alternative is provided, this would let those who > care about their RubyGems packaging help themselves, the way Apple did. > This isn't really a vendor-specific change. RUBY_FRAMEWORK_VERSION is supposed to be defined by Ruby builds that have been frameworki'zed (in a special directory bundle). Such a version could potentially be made for GNUStep too, for example. However, there was another change to support the Apple dual-repository configuration, which is this time purely vendor specific. I would also be glad to get rid of this change in the future. The 1.9 integration might help. Laurent _______________________________________________ Rubygems-developers mailing list [email protected] http://rubyforge.org/mailman/listinfo/rubygems-developers
