This might possibly just be an unmaintained post dep in the ebuild. * dev-ruby/rubygems ::gentoo 1.3.7 1.3.7-r1 1.3.7-r5(~) 1.8.24 1.8.25(~) 2.0.3(~)* {:0} dev-ruby/rubygems-2.0.3:0::gentoo Description Centralized Ruby extension management system Homepage http://rubyforge.org/projects/rubygems/ Herds ruby Use flags USE server Install support for the rubygems server (-test) Workaround to pull in packages needed to run with FEATURES=test. Portage-2.1.2 handles this internally, so don't set it in make.conf/package.use anymore ruby_targets -jruby Build with JRuby -ruby18 Build with MRI Ruby 1.8.x -ruby19 Build with MRI Ruby 1.9.x ruby20 Build with MRI Ruby 2.0.x Build Options symbols=strip How to handle debug symbols in installed files Permitted values: compress: Split and compress debug symbols preserve: Preserve debug symbols split: Split debug symbols strip: Strip debug symbols dwarf_compress Compress DWARF2+ debug information -optional_tests Run tests considered by the package to be optional -trace Trace actions executed by the package (very noisy, for debugging broken builds only) work=tidyup Whether to preserve or remove working directories Permitted values: leave: Do not remove, but allow destructive merges preserve: Perserve the working directory remove: Always remove the working directory tidyup: Tidy up work directory after a successful build Build dependencies [...] Post dependencies server? ( dev-ruby/builder[ruby_targets_ruby18] ) There is a description of running ruby gems server here which apparently sticks to ruby:1.9 http://guides.rubygems.org/run-your-own-gem-server/ For lack of interest and low personal priority, I did not try and test after manually patching the ebuild, if 1.9 or 2.0 works. However this might be a major blocker for people migrating away fully from 1.8 Finding this was pretty quick thanks to paludis superb --explain option - in this case --explain builder Best Regards Reproducible: Always
(In reply to cmuelle8 from comment #0) > --explain builder Correction: The full command used was cave resolve -X rake ruby:2.0 Paludis lead to the offending package "builder" by explaining the decisions made for pulling in "rake".
Do you actually need/use the USE=server part? If so, how?
I do not, but there are peers that might. I'm not the only one using this build, so you should not care about my singleton case. I've just disabled the flag, but it should be fixed nevertheless. If it works with 1.9, according to the blogpost it does, and possibly 2.0 the deps are wrong. Wrong deps are wrong :) .. and should be fixed. This also fixes dependents of the wrong deps, etc., this is why we should care for good and true deps at all. Greetings
(In reply to cmuelle8 from comment #3) > I do not, but there are peers that might. I'm not the only one using this > build, so you should not care about my singleton case. I wonder if anybody actually uses this at all, which is why I asked. > I've just disabled the flag, but it should be fixed nevertheless. If it > works with 1.9, according to the blogpost it does, and possibly 2.0 the deps > are wrong. Wrong deps are wrong :) .. and should be fixed. This also > fixes dependents of the wrong deps, etc., this is why we should care for > good and true deps at all. Agreed that it should be fixed in any case. Since the source code itself does not list any specific requirements I've simply changed the dependency to depend on builder.
(In reply to Hans de Graaff from comment #4) > Agreed that it should be fixed in any case. Since the source code itself > does not list any specific requirements I've simply changed the dependency > to depend on builder. Thanks (also for fixing rdoc stuff).
