# instructions to reproduce: # emerge --unmerge '>=virtual/ruby-ssl-1' # emerge -1vn virtual/ruby-ssl-0 verify that NOTHING in the deptree brings in REE or ruby-ssl-3. # emerge -uDpv @installed These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] dev-lang/ruby-enterprise-1.8.7.2010.02-r1 USE="berkdb gdbm ipv6 ncurses readline ssl threads -debug -doc -examples (-fastthreading) -libedit -rubytests -tcmalloc -tk -xemacs" 7,656 kB [ebuild NS ] virtual/ruby-ssl-3 [0] RUBY_TARGETS="(ree18)" 0 kB The problem here is that Portage is trying to upgrade virtual/ruby-ssl, and the fake versioning causes problems with that. I think that all ruby-ssl ebuilds should be merged into one, using RUBY_TARGET conditionals for each variant, but maybe zmedico has a better suggestion.
We moved to split ebuild because it's _much_ cleaner to keyword them and maintain keywords for them… maybe we should haver reverted the order of them though… still, if Zac has an idea how to avoid this it'd be nice…
I'm not really sure that this is a real bug, because as far as I can tell this will only happen when "ree18" is in RUBY_TARGETS, and in that case you've indicated that you want ruby-enterprise on your system. Or does this still happen when you only have RUBY_TARGETS="ruby18"?
(In reply to comment #0) > The problem here is that Portage is trying to upgrade virtual/ruby-ssl, and the > fake versioning causes problems with that. The @installed set doesn't generate slot atoms for cases in which there is only a single slot installed. This is why it pulls in virtual/ruby-ssl instead of virtual/ruby-ssl:0. I think the @installed set just needs to be fixed to pull in slot atoms in any case.
(In reply to comment #3) > (In reply to comment #0) > > The problem here is that Portage is trying to upgrade virtual/ruby-ssl, and the > > fake versioning causes problems with that. > > The @installed set doesn't generate slot atoms for cases in which there is only > a single slot installed. This is why it pulls in virtual/ruby-ssl instead of > virtual/ruby-ssl:0. I think the @installed set just needs to be fixed to pull > in slot atoms in any case. This is fixed in git: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=02b28820ba8ea3e760110ae156c70e6ee0457048 If you're satisfied with this solution then please re-assign to dev-portage.
The @installed thing is the only problem I see here, so I'll re-assign to dev-portage.
This is fixed in 2.2.0_alpha47.
