The package ompload at my stable system pulled in ruby-1.8 An "emerge --tree --update --keep-going --verbose --autounmask=n --nospinner --quiet-build=y --deep @world" then installed rube-1.9 too -although no package at my system depends on it. (And the ruby USE flag isn't set). Reproducible: Always
I actually rely on this feature. For eg. xfce4-meta depends on x11-themes/gtk-engines-xfce:0 and I rely on Portage to pull in the :3 SLOT by world upgrade. As in, new SLOTs should get always installed since they present an upgrade. I propose to close as WONTFIX
The policy has always been to pull in the highest visible version to satisfy any dependency. If you don't want the highest version, use /etc/portage/package.mask to mask it.
Well, if it is wanted ... (In reply to comment #2) > The policy has always been to pull in the highest visible version to satisfy > any dependency. Right, it is just unclear for me, where at my system is this "any dependency" on the new slotted version. (OTOH I should continue this in the forum rather than asking here I think ...) >If you don't want the highest version, use /etc/portage/package.mask to mask it. yep - of course.
(In reply to comment #3) > Right, it is just unclear for me, where at my system is this "any > dependency" on the new slotted version. Yes, the new slot will only get pulled in if it's matched by a dependency atom.
(In reply to comment #4) > (In reply to comment #3) > > Right, it is just unclear for me, where at my system is this "any > > dependency" on the new slotted version. > > Yes, the new slot will only get pulled in if it's matched by a dependency > atom. Hhm, then I'm wondering, if there's a bug in portage, because I do not have ruby set in my USE flags and with these result set only ompload requires ruby-1.8 : * These packages depend on ruby: app-editors/vim-7.3.409 (ruby ? =dev-lang/ruby-1.8*) app-misc/ompload-20101220 (>=dev-lang/ruby-1.8) dev-ruby/hoe-2.12.5 (ruby_targets_ruby18 ? dev-lang/ruby:1.8) (ruby_targets_ruby19 ? dev-lang/ruby:1.9) dev-ruby/json-1.5.4-r1 (ruby_targets_ruby18 ? dev-lang/ruby:1.8) (ruby_targets_ruby19 ? dev-lang/ruby:1.9) dev-ruby/minitest-2.12.1 (ruby_targets_ruby18 ? dev-lang/ruby:1.8) (ruby_targets_ruby19 ? dev-lang/ruby:1.9) dev-ruby/racc-1.4.6-r1 (ruby_targets_ruby18 ? dev-lang/ruby:1.8) (ruby_targets_ruby19 ? dev-lang/ruby:1.9) dev-ruby/rake-0.8.7-r6 (ruby_targets_ruby18 ? dev-lang/ruby:1.8) (ruby_targets_ruby19 ? dev-lang/ruby:1.9) dev-ruby/rdoc-3.12 (ruby_targets_ruby18 ? dev-lang/ruby:1.8) (ruby_targets_ruby19 ? dev-lang/ruby:1.9) (ruby_targets_ruby19 ? >=dev-lang/ruby-1.9.2:1.9) (ruby_targets_ruby18 ? >=dev-lang/ruby-1.8.7:1.8) dev-ruby/rubyforge-2.0.4-r2 (ruby_targets_ruby18 ? dev-lang/ruby:1.8) (ruby_targets_ruby19 ? dev-lang/ruby:1.9) dev-ruby/rubygems-1.8.24 (ruby_targets_ruby18 ? dev-lang/ruby:1.8) (ruby_targets_ruby19 ? dev-lang/ruby:1.9) (ruby_targets_ruby19 ? >=dev-lang/ruby-1.9.3_rc1) dev-vcs/subversion-1.6.17-r7 (ruby ? >=dev-lang/ruby-1.8.2) sci-libs/gdal-1.8.1-r1 (ruby ? dev-lang/ruby:1.8) virtual/ruby-rdoc-0 (ruby_targets_ruby18 ? dev-lang/ruby:1.8) (dev-lang/ruby:1.8) virtual/ruby-rdoc-1 (ruby_targets_ruby19 ? dev-lang/ruby:1.9) (<dev-lang/ruby-1.9.2_rc2-r1:1.9) virtual/ruby-ssl-0 (ruby_targets_ruby18 ? dev-lang/ruby:1.8) (dev-lang/ruby:1.8[ssl]) virtual/ruby-ssl-1 (ruby_targets_ruby19 ? dev-lang/ruby:1.9) (dev-lang/ruby:1.9[ssl]) virtual/ruby-test-unit-0-r4 (ruby_targets_ruby18 ? dev-lang/ruby:1.8) (ruby_targets_ruby19 ? dev-lang/ruby:1.9) virtual/rubygems-1 (ruby_targets_ruby18 ? dev-lang/ruby:1.8) virtual/rubygems-4 (ruby_targets_ruby19 ? dev-lang/ruby:1.9) www-client/elinks-0.11.7 (ruby ? dev-lang/ruby)
Create a debug log like this and attach it: emerge --pretend --depclean --debug ruby &>debug.log
Created attachment 317948 [details] debug log
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > Right, it is just unclear for me, where at my system is this "any > > > dependency" on the new slotted version. > > > > Yes, the new slot will only get pulled in if it's matched by a dependency > > atom. > > Hhm, > then I'm wondering, if there's a bug in portage, because I do not have ruby > set in my USE flags and with these result set only ompload requires ruby-1.8 > : No, it requires >=1.8, which means that it can pull in 1.0: > app-misc/ompload-20101220 (>=dev-lang/ruby-1.8)
Also, your debug log shows that you have ruby_targets_ruby19 enabled, which you should probably disable if you don't want ruby:1.9.
well - thx for your reply. I got rid of the old ruby by unmerging all ruby packages, setting RUBY_TARGETS="ruby19" into make.conf and updating @world.
