I'm trying to install a system with only RUBY_TARGETS="ree18". Thus, rake was installed with gems only in the rubyee path. Trying to invoke rake now yields the following error: vweb004 ~ # rake /usr/bin/rake:8:in `load': no such file to load -- /usr/lib64/ruby/gems/1.8/gems/rake-0.8.7/bin/rake (LoadError) from /usr/bin/rake:8 This, in consequence, makes other ebuilds fail as they may require a working rake (e.g. passenger). Output of "eselect ruby list": Available Ruby profiles: [1] rubyee18 (with Rubygems) * Reproducible: Always Steps to Reproduce: 1. set RUBY_TARGETS in make.conf to "ree18" only 2. emerge "rake" 3. invoke "rake" on the command line
We currently don't support a setup with -ruby18. What does 'ls -l /usr/bin/ruby' say?
(In reply to comment #1) > We currently don't support a setup with -ruby18. > > What does 'ls -l /usr/bin/ruby' say? It says this: # ls -l /usr/bin/ruby lrwxrwxrwx 1 root root 8 Nov 23 16:33 /usr/bin/ruby -> rubyee18 which means, ruby SHOULD BE looking in /usr/lib64/rubyee/gems/, and that's where the rake stuff is installed: # ls -ld /usr/lib64/rubyee/gems/1.8/gems/rake* drwxr-xr-x 4 root root 26 Nov 23 15:09 /usr/lib64/rubyee/gems/1.8/gems/rake-0.8.7 But when invoking the rake command, it get's the wrong gem path: vweb004 ~ # cat /usr/bin/rake #!/usr/bin/rubyee18 # This is a simplified version of the RubyGems wrapper # # Generated by ruby-fakegem.eclass : 1.24 $ require 'rubygems' puts Gem::default_path[-1] #<-- added for debugging load Gem::default_path[-1] + "/gems/rake-0.8.7/bin/rake" Output is now: # rake /usr/lib64/ruby/gems/1.8 /usr/bin/rake:9:in `load': no such file to load -- /usr/lib64/ruby/gems/1.8/gems/rake-0.8.7/bin/rake (LoadError) from /usr/bin/rake:9 "Gem::default_path" simply returns the wrong path...
BTW: This all doesn't fit together. Why does the rake command shebang line reference rubyee18 statically, and not the ruby symlink which is maintained by "eselect ruby"?
Okay, I upgraded to rubygems-1.3.7-r4 which seems to fix the search path. But the shebang line is still static and not symlinked.
The eclass documentation says: # Try to find out whether the package is going to install for # one or multiple implementations; if we're installing for a # *single* implementation, no need to use “/usr/bin/env ruby” # in the shebang, and we can actually avoid errors when # calling the script by default (see for instance the # JRuby-specific commands). So that explains why you have /usr/bin/rubyee18 linked directly. @Diego: not sure if this is a good, idea, since this won't handle people adding additional implementations later and then switching. @Kai: as far as I can tell your real bug was the broken search path which is fixed with the latest version of rubygems, and we can close this bug, right?
(In reply to comment #5) > So that explains why you have /usr/bin/rubyee18 linked directly. I see. But the point is, that "rake" is not targetted to a _SINGLE_ implementation: The ebuild supports multiple ruby targets and even installs its gems there. I even don't see any such restriction in the ebuild. > @Diego: not sure if this is a good, idea, since this won't handle people adding > additional implementations later and then switching. Who said what? Seeing no comment... > @Kai: as far as I can tell your real bug was the broken search path which is > fixed with the latest version of rubygems, and we can close this bug, right? What if I installed "rake" with more than one ruby target? Maybe it can be closed, not sure currently. I have never tried installing rake with more than one target set.
(In reply to comment #6) > I see. But the point is, that "rake" is not targetted to a _SINGLE_ > implementation: It is on your system since you only have one RUBY_TARGET defined. > What if I installed "rake" with more than one ruby target? Maybe it can be > closed, not sure currently. I have never tried installing rake with more than > one target set. The problem you started this bug with is solved, right?
> (In reply to comment #6) > > I see. But the point is, that "rake" is not targetted to a _SINGLE_ > > implementation: > It is on your system since you only have one RUBY_TARGET defined. Okay - that explains. > The problem you started this bug with is solved, right? Probably yes. Resolving as fixed by upgrading rubygems.
