# Ruby 1.9.2, rubygems and gentoo linux **URL:** \ **Category:** ruby-talk\ **Created:** [8 October 2010 07:24 UTC](https://rubytalk.org/t/ruby-1-9-2-rubygems-and-gentoo-linux/60372 "2010-10-08T07:24:14Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![Stefano\_Crocco](https://avatars.discourse-cdn.com/v4/letter/s/5f9b8f/32.png) [@Stefano\_Crocco](https://rubytalk.org/u/Stefano_Crocco)\ **Post date:** [8 October 2010 07:24 UTC](https://rubytalk.org/t/ruby-1-9-2-rubygems-and-gentoo-linux/60372/1 "2010-10-08T07:24:14Z")
Hello to everyone. On Gentoo linux, I have installed both ruby 1.9.2 and ruby 1.8.7, both installed using emerge (the Gentoo package manager). This setup contains a gem executable (rubygems version 1.3.7) which uses ruby 1.8, called gem18 and one which uses ruby 1.9, called gem19. Yesterday, I was surprised to find that gem18 installs gems in /usr/local/lib/ruby/gems, while gem19 installs them under /usr/lib/ruby/gems and started to investigate the reason for this. After looking at the changelog of the Gentoo package, I discovered that Gentoo packagers chose to make rubygems install gems under /usr/local so that user- installed gems won't conflict with those installed by the package manager, which still installs them in /usr/lib/ruby/gems. According to the changelog, this should happen with both ruby 1.8 and 1.9. The way they accomplished this was to provide a operating\_system.rb file which is installed in the site\_ruby/rubygems/default directory for both ruby 1.8 and ruby 1.9. This file redefines some methods in the Gem module so that they return the customized installation paths (for example, Gem.default\_dir is changed to return "/usr/local/lib/ruby/gems/1.9.1" rather than "/usr/lib/ruby/gems/1.9.1"). Looking at the ruby and rubygems source code, it seems that providing this operating\_system.rb file is the correct way for packagers to customize the installation paths used by rubygems, so I tried to understand why this didn't work correctly with ruby 1.9. After a bit of experimentation, I understood what was happening: apparently, everytime ruby 1.9 is launched, it requires some files, including operating\_system.rb. According to the contents of $", the other files are: [encdb.so](http://encdb.so) and [transdb.so](http://transdb.so) (besides a mysterious [enumerator.so](http://enumerator.so) which is shown without its full path and which doesn't seems to exist anywhere in the ruby directory). So, the reason rubygems uses the wrong directory is that it is loaded \*after\* operating\_system.rb, and thus overwrites the methods defined there, restoring the original ones. After this discovery, I tried to understand why ruby loaded operating\_system.rb at startup. Playing a bit with the command line options, I found out the file wasn't loaded if I used the --disable-gem switch. So, calling ruby19 --disable-gem /usr/bin/gem19 environment produced the correct results. I tried looking at the ruby source code to see what was the exact effect of calling --disable-gem, but I'm not skilled enough in C to understand ruby initialization code. I also tried looking for references to operating\_system.rb in the source code (outside the rubygems directory) but the only place I found it mentioned is in gem\_prelude.rb which isn't installed on my system. With ruby 1.8, this issue doesn't happen because operating\_system.rb isn't loaded by ruby at startup, but only after other rubygems file, so the methods it defines aren't overwritten. After this long explaination (I'm sorry for this, but I wanted to make the situation clear), here are my questions: 1. is there someone else using ruby 1.9.2 (or maybe even 1.9.1, I'm not sure whether this issue also happened with ruby 1.9.1 or not) on Gentoo which can reproduce this issue? If so, I'll post a bug on the gentoo bugtraker (please, if you're using gentoo and ruby 1.9.2 and not seeing this problem, do tell me, so I'll know the problem I'm facing is related to my system's configuration) 2. does anyone know (or has any clue on) why ruby loads certain files at startup? Thanks in advance Stefano