The easiest way to describe what's going on is to give you steps to reproduce: 1) obtain any recent stage3. we'll use stage3-amd64-20150723.tar.bz2 2) get a chroot ready and just try to emerge ruby: # emerge -vp ruby These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] dev-libs/libyaml-0.1.6::gentoo USE="-doc -examples -static-libs {-test}" 0 KiB [ebuild N ] app-eselect/eselect-ruby-20131227::gentoo 0 KiB [ebuild N ] dev-util/ragel-6.7-r1::gentoo USE="-vim-syntax" 0 KiB [ebuild N ] dev-lang/ruby-2.1.6-r1:2.1::gentoo USE="berkdb gdbm ipv6 ncurses rdoc readline ssl -debug -doc -examples -rubytests -socks5 -xemacs" 0 KiB [ebuild N ] dev-lang/ruby-2.0.0_p645:2.0::gentoo USE="berkdb gdbm ipv6 ncurses rdoc readline ssl -debug -doc -examples -rubytests -socks5 -xemacs" CPU_FLAGS_X86="sse2" 0 KiB [ebuild N ] dev-lang/ruby-1.9.3_p551-r1:1.9::gentoo USE="berkdb gdbm ipv6 ncurses rdoc readline ssl yaml -debug -doc -examples -rubytests -socks5 -xemacs" 0 KiB [ebuild N ] dev-ruby/rubygems-2.2.5-r1::gentoo USE="-server {-test}" RUBY_TARGETS="ruby19 ruby20 ruby21" 0 KiB [ebuild N ] virtual/rubygems-10::gentoo RUBY_TARGETS="ruby19 ruby20 ruby21" 0 KiB [ebuild N ] dev-ruby/rake-0.9.6-r1::gentoo USE="-doc {-test}" RUBY_TARGETS="ruby19 ruby20 ruby21" 0 KiB [ebuild N ] dev-ruby/json-1.8.2-r1::gentoo USE="-doc {-test}" RUBY_TARGETS="ruby19 ruby20 ruby21" 149 KiB [ebuild N ] dev-ruby/racc-1.4.11::gentoo USE="-doc {-test}" RUBY_TARGETS="ruby19 ruby20 ruby21" 111 KiB [ebuild N ] dev-ruby/rdoc-4.0.1-r2::gentoo USE="-doc {-test}" RUBY_TARGETS="ruby19 ruby20 ruby21" 0 KiB Total: 12 packages (12 new), Size of downloads: 260 KiB The following USE changes are necessary to proceed: (see "package.use" in the portage(5) man page for more details) # required by dev-ruby/rdoc-4.0.1-r2::gentoo[ruby_targets_ruby21] # required by dev-lang/ruby-2.0.0_p645::gentoo[rdoc] # required by dev-ruby/rubygems-2.2.5-r1::gentoo[ruby_targets_ruby20] # required by virtual/rubygems-10::gentoo[ruby_targets_ruby19] # required by dev-lang/ruby-1.9.3_p551-r1::gentoo # required by dev-ruby/json-1.8.2-r1::gentoo[ruby_targets_ruby19] # required by dev-lang/ruby-2.1.6-r1::gentoo # required by dev-ruby/rake-0.9.6-r1::gentoo[ruby_targets_ruby21] >=dev-ruby/racc-1.4.11 ruby_targets_ruby21 # required by dev-lang/ruby-2.1.6-r1::gentoo # required by dev-ruby/rubygems-2.2.5-r1::gentoo[ruby_targets_ruby21] # required by virtual/rubygems-10::gentoo[ruby_targets_ruby19] # required by dev-lang/ruby-2.0.0_p645::gentoo # required by dev-ruby/json-1.8.2-r1::gentoo[ruby_targets_ruby20] # required by dev-ruby/rdoc-4.0.1-r2::gentoo[ruby_targets_ruby19] # required by dev-lang/ruby-1.9.3_p551-r1::gentoo[rdoc] # required by dev-ruby/racc-1.4.11::gentoo[ruby_targets_ruby19] >=dev-ruby/rake-0.9.6-r1 ruby_targets_ruby21 # required by dev-ruby/racc-1.4.11::gentoo[-test,ruby_targets_ruby21] # required by dev-ruby/rdoc-4.0.1-r2::gentoo[ruby_targets_ruby19] # required by dev-lang/ruby-2.0.0_p645::gentoo[rdoc] # required by dev-ruby/rubygems-2.2.5-r1::gentoo[ruby_targets_ruby20] >=virtual/rubygems-10 ruby_targets_ruby21 # required by dev-lang/ruby-2.1.6-r1::gentoo[rdoc] # required by dev-ruby/rubygems-2.2.5-r1::gentoo[ruby_targets_ruby21] # required by virtual/rubygems-10::gentoo[ruby_targets_ruby19] # required by dev-lang/ruby-2.0.0_p645::gentoo # required by dev-ruby/json-1.8.2-r1::gentoo[ruby_targets_ruby20] >=dev-ruby/rdoc-4.0.1-r2 ruby_targets_ruby21 # required by dev-ruby/rdoc-4.0.1-r2::gentoo[ruby_targets_ruby21] # required by dev-lang/ruby-2.0.0_p645::gentoo[rdoc] # required by dev-ruby/rubygems-2.2.5-r1::gentoo[ruby_targets_ruby20] # required by virtual/rubygems-10::gentoo[ruby_targets_ruby19] # required by dev-lang/ruby-1.9.3_p551-r1::gentoo # required by dev-ruby/rake-0.9.6-r1::gentoo[ruby_targets_ruby19] # required by dev-lang/ruby-2.1.6-r1::gentoo # required by dev-ruby/racc-1.4.11::gentoo[ruby_targets_ruby21] >=dev-ruby/json-1.8.2-r1 ruby_targets_ruby21 # required by virtual/rubygems-10::gentoo[ruby_targets_ruby21] # required by dev-lang/ruby-2.0.0_p645::gentoo # required by dev-ruby/json-1.8.2-r1::gentoo[ruby_targets_ruby20] # required by dev-lang/ruby-2.1.6-r1::gentoo # required by dev-ruby/rake-0.9.6-r1::gentoo[ruby_targets_ruby21] # required by dev-ruby/racc-1.4.11::gentoo[-test,ruby_targets_ruby20] # required by dev-ruby/rdoc-4.0.1-r2::gentoo[ruby_targets_ruby19] # required by dev-lang/ruby-1.9.3_p551-r1::gentoo[rdoc] >=dev-ruby/rubygems-2.2.5-r1 ruby_targets_ruby21 * IMPORTANT: 13 news items need reading for repository 'gentoo'. * Use eselect news read to view new items. Reproducible: Always
I'm reproducing this on many different systems, different arches and both hardened and vanilla profiles.
*** Bug 556386 has been marked as a duplicate of this bug. ***
In this specific case you are asking for the "best" version of ruby but the USE flags required for it are not set. You can either ask for a version in RUBY_TARGETS (e.g. emerge ruby:2.0) or adjust RUBY_TARGETS, or add the USE flags to package.use if all you want is the interpreter. I'm not sure what we could do to make this work better. This situation should hopefully(*) also not arise when doing a new installation, since in that case ruby will be pulled in as a dependency, and due to RUBY_TARGETS being set ruby:2.0 will be pulled in as the preferred ruby version first and satisfying the dev-lang/ruby dependency. * hopefully since it is still possible that packages may depend on dev-lang/ruby or on specific slots, we have created ruby-single.eclass for this situation. Having said all this, I did see a similar situation arise when doing a partial update on a server, e.g. with "emerge -uD system". The problem went away with "emerge -uD world". I haven't been able to find out what portage was thinking in this case. Was this also the trigger for you bug report? Or did you specifically try to emerge the latest ruby version?
(In reply to Hans de Graaff from comment #3) > In this specific case you are asking for the "best" version of ruby but the > USE flags required for it are not set. You can either ask for a version in > RUBY_TARGETS (e.g. emerge ruby:2.0) or adjust RUBY_TARGETS, or add the USE > flags to package.use if all you want is the interpreter. > > I'm not sure what we could do to make this work better. > > This situation should hopefully(*) also not arise when doing a new > installation, since in that case ruby will be pulled in as a dependency, and > due to RUBY_TARGETS being set ruby:2.0 will be pulled in as the preferred > ruby version first and satisfying the dev-lang/ruby dependency. > > * hopefully since it is still possible that packages may depend on > dev-lang/ruby or on specific slots, we have created ruby-single.eclass for > this situation. > > Having said all this, I did see a similar situation arise when doing a > partial update on a server, e.g. with "emerge -uD system". The problem went > away with "emerge -uD world". I haven't been able to find out what portage > was thinking in this case. Was this also the trigger for you bug report? Or > did you specifically try to emerge the latest ruby version? It arrises if you have "dev-lang/ruby" in your world file without any slots. So I'm hit this on a tinderbox-ish build where ruby is asked for directly, but lots of people will have just "dev-lang/ruby". In fact I had it on my main development desktop. This is not an unreasonable situation. I tried writing a virtual as discussed in IRC but I couldn't get it to work. I understand why you don't want to use.stable.mask it, because then certain code won't be tested, but arch teams can be instructed to lift that to properly test. Adding ruby21 to RUBY_TARGETS does work, but then why not add that for the arches on which its required? I know it might mean a lot of rebuilds for people, that's better than this kind of an impass. You can add it on a per arch basis and then fall back to base when all arches are done.
(In reply to Anthony Basile from comment #4) > > It arrises if you have "dev-lang/ruby" in your world file without any slots. Actually its worse that this. There are lots of packages in the tree that have dependencies like media-libs/mlt where RDEPEND=" ... ruby? ( dev-lang/ruby ) ..." This pull in the best version of ruby, ie ruby21, and then you get into the same situation. So its not necessary that you try to emerge ruby directly or have "dev-lang/ruby" in your world file, you can hit it on emerging media-lib/mlt or similarly dependant packages.
Yeah, it's quite annoying. I don't have ruby in my world file, but periodically portage tries to install ruby:2.1 and reinstall several packages with appropriate RUBY_TARGETS: $ emerge -pvuDN @world These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] net-dns/openresolv-3.7.0::gentoo [3.6.1::gentoo] USE="(-selinux)" 18 KiB [ebuild N ] dev-util/re2c-0.13.7.5::gentoo 2 293 KiB [ebuild U ] app-admin/logrotate-3.9.1::gentoo [3.8.9-r1::gentoo] USE="acl cron (-selinux)" 78 KiB [ebuild NS ] dev-lang/ruby-2.1.6-r1:2.1::gentoo [1.9.3_p551-r1:1.9::gentoo, 2.0.0_p645:2.0::gentoo] USE="berkdb examples gdbm ipv6 ncurses rdoc readline ssl -debug -doc -rubytests -socks5 -xemacs" 9 165 KiB [ebuild R ] dev-ruby/rubygems-2.2.5-r1::gentoo USE="-server {-test}" RUBY_TARGETS="ruby19 ruby20 ruby21*" 0 KiB [ebuild R ] virtual/rubygems-10::gentoo RUBY_TARGETS="ruby19 ruby20 ruby21*" 0 KiB [ebuild R ] dev-ruby/rake-0.9.6-r1::gentoo USE="-doc {-test}" RUBY_TARGETS="ruby19 ruby20 ruby21*" 0 KiB [ebuild R ] dev-ruby/json-1.8.2-r1::gentoo USE="-doc {-test}" RUBY_TARGETS="ruby19 ruby20 ruby21*" 0 KiB [ebuild R ] dev-ruby/racc-1.4.11::gentoo USE="-doc {-test}" RUBY_TARGETS="ruby19 ruby20 ruby21*" 0 KiB [ebuild R ] dev-ruby/rdoc-4.0.1-r2::gentoo USE="-doc {-test}" RUBY_TARGETS="ruby19 ruby20 ruby21*" 0 KiB [ebuild N ] x11-libs/libxkbui-1.0.2-r1::gentoo USE="-static-libs" 217 KiB [ebuild N ] dev-util/ninja-1.5.3::gentoo USE="vim-syntax -doc -emacs {-test} -zsh-completion" 165 KiB [ebuild U ] sys-apps/smartmontools-6.4::gentoo [6.3::gentoo] USE="caps -minimal (-selinux) -static" 804 KiB [ebuild U ] media-gfx/fontforge-20150430::gentoo [20110222-r1::gentoo] USE="X cairo gif gtk%* jpeg png python readline%* svg tiff unicode -truetype-debugger (-cjk%) (-debug%) (-doc%) (-nls%*) (-pango%) (-pasteafter%) (-tilepath%) (-truetype%*) (-type3%)" PYTHON_SINGLE_TARGET="python2_7%* -python3_3% -python3_4%" PYTHON_TARGETS="python2_7%* python3_4%* -python3_3%" 30 019 KiB Total: 14 packages (4 upgrades, 3 new, 1 in new slot, 6 reinstalls), Size of downloads: 42 755 KiB The following USE changes are necessary to proceed: (see "package.use" in the portage(5) man page for more details) # required by virtual/rubygems-10::gentoo[ruby_targets_ruby21] # required by dev-ruby/rdoc-4.0.1-r2::gentoo[-test,ruby_targets_ruby21] # required by dev-lang/ruby-2.1.6-r1::gentoo[rdoc] # required by dev-ruby/racc-1.4.11::gentoo[ruby_targets_ruby21] >=dev-ruby/rubygems-2.2.5-r1 ruby_targets_ruby21 # required by dev-lang/ruby-2.1.6-r1::gentoo[rdoc] # required by virtual/rubygems-10::gentoo[ruby_targets_ruby21] # required by dev-ruby/json-1.8.2-r1::gentoo[-test,ruby_targets_ruby21] # required by dev-lang/ruby-2.0.0_p645::gentoo # required by dev-ruby/racc-1.4.11::gentoo[ruby_targets_ruby20] >=dev-ruby/rdoc-4.0.1-r2 ruby_targets_ruby21 # required by dev-ruby/rdoc-4.0.1-r2::gentoo[ruby_targets_ruby21] # required by dev-lang/ruby-2.1.6-r1::gentoo[rdoc] # required by virtual/rubygems-10::gentoo[ruby_targets_ruby21] # required by dev-ruby/racc-1.4.11::gentoo[-test,ruby_targets_ruby21] >=dev-ruby/json-1.8.2-r1 ruby_targets_ruby21 # required by dev-lang/ruby-2.1.6-r1::gentoo # required by virtual/rubygems-10::gentoo[ruby_targets_ruby21] # required by dev-ruby/rdoc-4.0.1-r2::gentoo[-test,ruby_targets_ruby21] # required by dev-lang/ruby-1.9.3_p551-r1::gentoo[rdoc] # required by dev-ruby/racc-1.4.11::gentoo[ruby_targets_ruby19] >=dev-ruby/rake-0.9.6-r1 ruby_targets_ruby21 # required by dev-ruby/rdoc-4.0.1-r2::gentoo[ruby_targets_ruby21] # required by dev-lang/ruby-2.1.6-r1::gentoo[rdoc] # required by virtual/rubygems-10::gentoo[ruby_targets_ruby21] # required by dev-ruby/json-1.8.2-r1::gentoo[-test,ruby_targets_ruby21] # required by dev-lang/ruby-2.0.0_p645::gentoo # required by dev-ruby/rake-0.9.6-r1::gentoo[ruby_targets_ruby20] >=dev-ruby/racc-1.4.11 ruby_targets_ruby21 # required by dev-lang/ruby-2.1.6-r1::gentoo # required by dev-ruby/racc-1.4.11::gentoo[ruby_targets_ruby21] # required by dev-ruby/rdoc-4.0.1-r2::gentoo[ruby_targets_ruby21] # required by dev-lang/ruby-1.9.3_p551-r1::gentoo[rdoc] # required by dev-ruby/rake-0.9.6-r1::gentoo[ruby_targets_ruby19] # required by dev-ruby/json-1.8.2-r1::gentoo[-doc,-test,ruby_targets_ruby21] # required by dev-lang/ruby-2.0.0_p645::gentoo # required by dev-ruby/rubygems-2.2.5-r1::gentoo[ruby_targets_ruby20] >=virtual/rubygems-10 ruby_targets_ruby21 !!! All ebuilds that could satisfy ">=dev-ruby/rubygems-2.0.14[ruby_targets_ruby21]" have been masked. !!! One of the following masked packages is required to complete your request: - dev-ruby/rubygems-2.4.8::gentoo (masked by: ~amd64 keyword) - dev-ruby/rubygems-2.4.6::gentoo (masked by: ~amd64 keyword) - dev-ruby/rubygems-2.2.5-r1::gentoo (masked by: ) (dependency required by "virtual/rubygems-10::gentoo[ruby_targets_ruby21]" [ebuild]) (dependency required by "dev-lang/ruby-2.1.6-r1::gentoo" [ebuild]) (dependency required by "dev-ruby/racc-1.4.11::gentoo[ruby_targets_ruby21]" [ebuild]) (dependency required by "dev-ruby/rdoc-4.0.1-r2::gentoo[ruby_targets_ruby21]" [ebuild]) (dependency required by "dev-lang/ruby-1.9.3_p551-r1::gentoo[rdoc]" [installed]) (dependency required by "dev-ruby/rake-0.9.6-r1::gentoo[ruby_targets_ruby19]" [ebuild]) (dependency required by "dev-ruby/json-1.8.2-r1::gentoo[-doc,-test,ruby_targets_ruby21]" [ebuild]) (dependency required by "dev-lang/ruby-2.0.0_p645::gentoo" [installed]) (dependency required by "dev-ruby/rubygems-2.2.5-r1::gentoo[ruby_targets_ruby20]" [ebuild]) For more information, see the MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook.
This is probably due to the following package installed: $ equery -CN depends dev-lang/ruby | grep -v 'ruby.*:' media-video/mkvtoolnix-6.6.0 (dev-lang/ruby)
(In reply to Anthony Basile from comment #4) > It arrises if you have "dev-lang/ruby" in your world file without any slots. > So I'm hit this on a tinderbox-ish build where ruby is asked for directly, > but lots of people will have just "dev-lang/ruby". In fact I had it on my > main development desktop. This is not an unreasonable situation. > > I tried writing a virtual as discussed in IRC but I couldn't get it to work. The version you posted used DEPEND instead of RDEPEND, so that may have been the cause. In any case your version made me realize we can leverage the mechanism in ruby-single.eclass for this. I have now added virtual/ruby based on this. > I understand why you don't want to use.stable.mask it, because then certain > code won't be tested, but arch teams can be instructed to lift that to > properly test. I'll discuss this with the ruby team and arch teams, but it will not be possible to use this until ruby22, given that ruby21 is already stable now. > Adding ruby21 to RUBY_TARGETS does work, but then why not add that for the > arches on which its required? I know it might mean a lot of rebuilds for > people, that's better than this kind of an impass. You can add it on a per > arch basis and then fall back to base when all arches are done. There are two concerns with that: people may not just install but also eselect it and then be disappointed since not many other ruby packages already have ruby21 versions stable. That situation will obviously improve over time. The other concern is that people get really frustrated from having three ruby versions installed. What we ended up doing for ruby20 is to force the ruby21 USE flag on the core set of packages but that is also not a very nice solution.
I tested this and, as expected, it doesn't fix the current issue. How will it work for ruby22, ie can you give me steps to verify at my end what will happen with ruby22?
(In reply to Anthony Basile from comment #9) > I tested this and, as expected, it doesn't fix the current issue. How will > it work for ruby22, ie can you give me steps to verify at my end what will > happen with ruby22? Actually mrueg had a good idea for ruby22: the arches should just ack that ruby22 works on their respectively architecture and then when all have acked, the ruby team can stabilize all arches at once and set RUBY_TARGETS simultaneously.
I'm encountering this issue. The source of the problem for me seems to be www-client/elinks, via a dependency like the one described in comment #5. It seems obvious to me that this would happen whenever something (world file, a package, etc) depends on bare dev-lang/ruby without a version or slot. I'm also noticing that most of the "# required by" lines reported by portage in this case are completely bogus...
So what a desktop user have to do? Putting RUBY_TARGETS="ruby19 ruby20 ruby21" in the make.conf? Putting only RUBY_TARGETS="ruby21"? Why is not the profile update? make.defaults (desktop profile), we have # Manuel Rüger <mrueg@gentoo.org> (16 Mar 2014) # Default Ruby build targets RUBY_TARGETS="ruby19 ruby20" For me $ equery -CN depends dev-lang/ruby | grep -v 'ruby.*:' dev-qt/qtwebkit-5.4.2 (dev-lang/ruby) media-video/mkvtoolnix-6.6.0 (dev-lang/ruby)
(In reply to sebB from comment #12) > So what a desktop user have to do? > > Putting RUBY_TARGETS="ruby19 ruby20 ruby21" in the make.conf? > Yes. Hopefully this will be the last time. In the future the ruby team will either make use of the virtual, or (what I think is the better option), have the arches just ack stabilization for ruby22 and when all the arches have acked, ruby22 is marked stable across the board and simultaneously the appropriate ruby targets are set in the profiles. I understand why the ruby team proceeded as they did, but it had this unfortunately consequence. Also, they ruby team might consider making use of the ruby equivalent of PYTHON_USEDEPS to avoid dependencies like >=dev-ruby/json-1.8.1[ruby_targets_ruby21] which is what caused the problem ... pulling in the "best" version of ruby meant pulling in dev-ruby/json with RUBY_TARGETS="ruby21" which was not yet set in the profiles.
(In reply to Anthony Basile from comment #13) > (In reply to sebB from comment #12) > > So what a desktop user have to do? > > > > Putting RUBY_TARGETS="ruby19 ruby20 ruby21" in the make.conf? > > > > Yes. Hopefully this will be the last time. In the future the ruby team > will either make use of the virtual, or (what I think is the better option), > have the arches just ack stabilization for ruby22 and when all the arches > have acked, ruby22 is marked stable across the board and simultaneously the > appropriate ruby targets are set in the profiles. > > I understand why the ruby team proceeded as they did, but it had this > unfortunately consequence. Also, they ruby team might consider making use > of the ruby equivalent of PYTHON_USEDEPS to avoid dependencies like > >=dev-ruby/json-1.8.1[ruby_targets_ruby21] which is what caused the problem > ... pulling in the "best" version of ruby meant pulling in dev-ruby/json > with RUBY_TARGETS="ruby21" which was not yet set in the profiles. Hans, I think we're done with this one seeing as we are now up to ruby21. I'm going to close it but you may want to reopen if the underlying issue hasn't been resolved.
