[Rubygems-developers] Bug#588125: Rubygems 1.3.7 broken with Ruby 1.9.2 in Debian -- help needed

Lucas Nussbaum lucas at lucas-nussbaum.net
Sat Aug 28 02:56:05 EDT 2010


On 26/08/10 at 08:25 +0900, akira yamada wrote:
> 2010/8/26 Lucas Nussbaum <lucas at lucas-nussbaum.net>:
> > That worked fine until Ruby 1.9.1, but apparently a change in Ruby
> > 1.9.2 broke Rubygems 1.3.7. This is exhibited by two bugs:
> [...]
> > - rubygems doesn't work:
> >  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588125
> 
> I trace the following error:
> --
> $ gem1.9.1 list
> /usr/lib/ruby/1.9.1/rubygems.rb:634:in `path': undefined method `path'
> for #<Gem::ConfigFile:0x000000014a09d8> (NoMethodError)
> --
> 
> I got a result:
> --
> $ ruby1.9.1 -e 'p Gem.path; require "rubygems"; p Gem.path'
> ["/home/akira/.gem/ruby/1.9.1", "/usr/lib/ruby/gems/1.9.1"]
> /usr/lib/ruby/1.9.1/rubygems/source_index.rb:68:in
> `installed_spec_directories': undefined method `path' for Gem:Module
> (NoMethodError)
> 
> $ ruby1.9.1 -e 'p Gem.path; begin; require "not exist"; rescue
> LoadError; end; require "rubygems"; p Gem.path'
> ["/home/akira/.gem/ruby/1.9.1", "/usr/lib/ruby/gems/1.9.1"]
> ["/home/akira/.gem/ruby/1.9.1", "/var/lib/gems/1.9.1"]
> 
> $ ruby1.9.1 -e 'p Gem.path; Gem::QuickLoader.remove; require
> "rubygems"; p Gem.path'                                          ~
> ["/home/akira/.gem/ruby/1.9.1", "/usr/lib/ruby/gems/1.9.1"]
> ["/home/akira/.gem/ruby/1.9.1", "/var/lib/gems/1.9.1"]
> --
> 
> There is difference:
> --
> $ diff -u ruby_1_9_2/lib/rubygems.rb /usr/lib/ruby/1.9.1/rubygems.rb |head -20
> --- ruby_1_9_2/lib/rubygems.rb	2010-08-02 09:53:36.000000000 +0900
> +++ /usr/lib/ruby/1.9.1/rubygems.rb	2010-08-26 07:05:24.000000000 +0900
> @@ -4,14 +4,8 @@
>  # All rights reserved.
>  # See LICENSE.txt for permissions.
>  #++
> -
>  gem_disabled = !defined? Gem
> 
> -unless gem_disabled
> -  # Nuke the Quickloader stuff
> -  Gem::QuickLoader.remove
> -end
> -
>  require 'rubygems/defaults'
>  require 'thread'
>  require 'etc'
> @@ -492,8 +486,26 @@
> 
>    ##
> --
> (ruby_1_9_2 is tree of ruby_1_9_2 in the svn.
> /usr/lib/ruby/1.9.1/rubygems.rb is provided rubygems-1.3.1.deb)
> 
> When ruby requires "rubygems", rubygems.rb will require
> "rubygems/defaults/operating_system".
> And ruby re-requires "rubygems" internally because the file is not given.
> 
> On the 2nd require "rubygems", Gem::QuickLoader.remove is called.
> The method removes Gem module methods defined in gem_prelude.
> But the 2nd require "rubygems" don't executed because ruby interpreter
> is already in requiring rubygems.
> So some pre-defined Gem module methods is missing
> and chance of new definition of these methods isn't given.
> 
> Calling Gem::QuickLoader.remove in top of rubygems.rb
> can avoid "circular require" of rubygems.
> (It sets @loaded_full_rubygems_library)

Thanks for the investigation!

After looking at this issue, I think that we should:
- package rubygems1.8 from rubygems 1.3.7
- package rubygems for 1.9.1 from the ruby 1.9.2 sources

While it's not the cleanest approach, it seems that it is the most
reasonable solution given that upstream has failed to make sure that
ruby1.9.2 wouldn't break with rubygems's rubygems. It might happen again
in the future.

We need to decide on the following questions:

- Do we want to make the installation of rubygems optional with 1.9.1?
  (as a separate package ?) That would probably be the right thing to do
  since I think that we should make the use of external package managers
  optional in Debian, but frankly, if we do that, some users are going
  to complain, and I'm totally tired of hearing complains about ruby
  packaging in Debian.
- Do we want to disable gem update --system? I think that we should
  allow a way for the user to do it anyway. For example, we could add a
  check for a "I_KNOW_WHAT_IM_DOING_ABOUT_GEM_UPDATE_SYSTEM" environment
  variable (ok, name could be improved). We would still refuse to gem
  update --system by default, but would accept it of the environment
  variable was set.
- Paths: until consensus emerge in #448639, we should continue to
  install gems in /var. Those changes should be moved to 
  rubygems/defaults/operating_system.rb, but we may do that later, and
  just continue with 01_default_gem_path.diff for now.

Lucas


More information about the Rubygems-developers mailing list