[Rubygems-developers] gem update --system probably broken on OSX
laurent.sansonetti at gmail.com
Tue Nov 27 17:11:08 EST 2007
On Nov 27, 2007 8:40 PM, Mauricio Fernandez <mfp at acm.org> 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'])
> File.join(Config::CONFIG['libdir'], 'ruby', 'gems', Config::CONFIG['ruby_version'])
> 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
More information about the Rubygems-developers