[Rubygems-developers] gem update --system probably broken on OSX

Mauricio Fernandez mfp at acm.org
Tue Nov 27 18:38:51 EST 2007

On Tue, Nov 27, 2007 at 11:11:08PM +0100, Laurent Sansonetti wrote:
> 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'])
> >        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.

(What happens if:
* you are using Tiger & have a number of gems installed
* you upgrade from Tiger to Leopard

It looks like the path changes both when RUBY_FRAMEWORK_VERSION was defined
(because CONFIG["ruby_version"] is appended) and when it wasn't.)

As I said, I haven't experienced this myself. I got a bug report for FastRI
caused by this path modification, and I was told that  gem update --system
didn't work properly. There might be some other reason for that.

On further reflection, this doesn't matter that much anyway, since binary
compatibility is not ensured across minor Ruby releases. It'd be nice if
RubyGems were smart enough to know against which ABI the extensions were
built, recompile when needed, and migrate all the pure-Ruby libs.

> > 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.

Yes, I was referring to APPLE_GEM_HOME.
The 1.9 integration only helps to the extent that it makes easier to
standardize changes in rbconfig.rb, but 1.8 needs a solution more urgently.

Mauricio Fernandez  -   http://eigenclass.org

More information about the Rubygems-developers mailing list