Summary: | Rubygems and Ruby-1.9.* - operating_system.rb is being ignored. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Codo <arturogarcia> |
Component: | [OLD] Development | Assignee: | Gentoo Ruby Team <ruby> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | chewi, danchenkoff, stefano.crocco |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 203706 |
Description
Codo
2010-09-11 21:00:18 UTC
I suggest moving/copying temporarily the contents of operating_system.rb to another file, and requiring it manually from the rubygems.rb file. I know, it's nasty.... But, can't think of any other solution, other than fixing gem_prelude... Wouldn't a patch replacing the line require 'rubygems/defaults/operating_system' in rubygems.rb (line number 1096) with load 'rubygems/defaults/operating_system.rb' solve the problem? Unless I'm mistaken, this issue is caused by the fact that, since operating_system.rb has already been loaded when rubygems.rb is required, requiring it again from rubygems.rb has no effect, since require won't do nothing if the required file has already been loaded. load, instead, doesn't have this behaviour, and will always load the file. Using it, operating_system.rb would be loaded a second time from rubygems.rb, thus overwriting the methods defined by rubygems as it's supposed to do. I tried applying this change to rubygems.rb on my system and a quick test seems to show it works. (In reply to comment #2) > Wouldn't a patch replacing the line > > require 'rubygems/defaults/operating_system' > > in rubygems.rb (line number 1096) with > > load 'rubygems/defaults/operating_system.rb' > > solve the problem? It seems like it will. Looking at the sources on 1.9.2-p0, the chain of calls in require and load are: rb_load --> rb_load_internal --> rb_load_file rb_require --> rb_require_safe --> rb_load_internal --> rb_load_file (both from load.c) I haven't looked really into the exact behaviour of rb_require, but I think it will work. > Unless I'm mistaken, this issue is caused by the fact that, since > operating_system.rb has already been loaded when rubygems.rb is required, > requiring it again from rubygems.rb has no effect, since require won't do > nothing if the required file has already been loaded. load, instead, doesn't > have this behaviour, and will always load the file. Using it, > operating_system.rb would be loaded a second time from rubygems.rb, thus > overwriting the methods defined by rubygems as it's supposed to do. Indeed. I agree as well that would be fix. > I tried applying this change to rubygems.rb on my system and a quick test seems > to show it works. > I am patching my system now with the change (I am using 1.9.2) and will post back! Any further feedback from the folks who have been testing this fix? I'd like to add this fix to CVS and unmask ruby 1.9, so some additional feedback would be helpful. I've been testing replacing require with load in line 1096 of rubygems.rb as I suggested in comment #2 since October, and everything works correctly. The only issue is that this causes two warnings due to portage_gems_dir and system_config_path being overwritten when operating_system.rb is loaded the second time. This can be solved by adding the lines undef :portage_gems_dir rescue nil and undef :system_config_path rescue nil just before defining these methods in operating_system.rb My system is still using require (not load), but I might have hacked it somewhere else when I encountered the problem. I suggest reading the link I attached and put in a clean install. I'm sorry i can't break my install right now (I am working and have no time). Good luck folks! (I encountered the problem when executing gem install as root....) (In reply to comment #5) > I've been testing replacing require with load in line 1096 of rubygems.rb as I > suggested in comment #2 since October, and everything works correctly. Stefano, I checked again and I am running with require... Can you make it fail by switching back to 'require'? Additionally, can you post the output of your $ equery list rubygems $ equery list ruby (In reply to comment #7) > (In reply to comment #5) > > I've been testing replacing require with load in line 1096 of rubygems.rb as I > > suggested in comment #2 since October, and everything works correctly. > Stefano, I checked again and I am running with require... Can you make it fail > by switching back to 'require'? > > Additionally, can you post the output of your > $ equery list rubygems > $ equery list ruby > Using require instead of load, the GEM PATHS as reported by gem env is: - /usr/lib/ruby/gems/1.9.1 - /home/stefano/.gem/ruby/1.9.1 Changing it to use load, it becomes: - /usr/local/lib/ruby/gems/1.9.1 - /home/stefano/.gem/ruby/1.9.1 - /usr/lib/ruby/gems/1.9.1 equery list rubygems gives: [IP-] [ ] dev-ruby/rubygems-1.3.7-r4:0 equery list ruby gives [IP-] [ ] dev-lang/ruby-1.8.7_p302:1.8 [IP-] [ ] dev-lang/ruby-1.9.2:1.9 I tried changing that line to load and it doesn't make any difference. Does this still work for you, Stefano? Downgrade to dev-lang/ruby-1.9.2.... dev-lang/ruby-1.9.2-r1's got a bug.... As usual, no time, but you can check what patches are being applied. As per the 'load' / 'require' change, it doesn't seem to matter anymore.... It looks like newer versions of rubygems (1.7.2) no longer have operating_system.rb at all, so my plan is to patch the defaults.rb directly with support for our setup in those newer versions. That should also work in the case where rubygems is required directly, and thus fix things for ruby 1.9. (In reply to comment #11) > It looks like newer versions of rubygems (1.7.2) no longer have > operating_system.rb at all, so my plan is to patch the defaults.rb directly > with support for our setup in those newer versions. That should also work in > the case where rubygems is required directly, and thus fix things for ruby 1.9. Actually these versions do still support operating_system.rb, so this needs to be tested with a newer rubygems version, and possible fixed in rubygems. Please try rubygems-1.8.7 (p.masked), it should fix the issue. This is fixed with ruby 1.9.3_rc1 which I added to the tree today in combination with a new rubygems. |