Okay I am now using ruby19, This have solved my problem. Thanks stephen # eselect ruby list Available Ruby profiles: [1] ruby19 (with Rubygems) * [2] ruby20 (with Rubygems)
stephen # ls -l /usr/bin/rdoclrwxrwxrwx 1 root root 6 Jun 8 11:45 /usr/bin/rdoc -> rdoc19 stephen # grep RUBY /etc/portage/make.conf RUBY_TARGETS="ruby19" On Sun, Jun 8, 2014 at 10:39 AM, Hans de Graaff <gra...@gentoo.org> wrote: > On Sat, 07 Jun 2014 17:20:22 -0700, walt wrote: > > > On 06/07/2014 12:56 AM, Hans de Graaff wrote: > > > For example, I (want to) use only ruby19: > > > > #grep RUBY /etc/portage/make.conf RUBY_TARGETS="ruby19" > > Yes, in hindsight I think that should have been the current default since > ruby19 has the best overall coverage for packages. Once ruby20 has caught > up I think we'll move to a default of RUBY_TARGETS="ruby20" > > > In spite of that, portage often insists on installing other versions of > > ruby, rdoc, rubygems, and you already know the others. > > Partially this was because we tried to solve another issue when ruby20 > went stable. I removed those forced use flags for ruby20 last week, so > this should no longer happen. We still need to come up with a good plan > when the same issue will pop up for ruby21. > > > AFAICT, the other versions of ruby are dragged in by old ruby packages > > that were installed before I started using "RUBY_TARGETS" (because I > > didn't yet know about RUBY_TARGETS), > > Yes, these will still have other ruby targets recorded and thus also > request them for their dependencies. emerge --newuse should be able to > help here. > > > I discovered all of this by grepping for ruby in /var/db/pkg but it took > > me a long time to get it sorted out, and I don't expect that a gentoo > > beginner could do it. (OTOH maybe a gentoo beginner wouldn't care about > > installing multiple ruby versions :) > > We try to keep the default settings so that someone who doesn't care or > know about ruby should get a good experience. Moving from ruby18 to ruby19 > we did some things that could have been handled better (such as not > mentioning that the new ruby must be eselected before making the switch), > so hopefully we've learned from those when we do the next update. > > Hans > > > >
