On 26/08/10 at 08:25 +0900, akira yamada wrote: > 2010/8/26 Lucas Nussbaum <lu...@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 -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
