Bug 338959 – virtual/ruby-ssl: Having any version of ruby-ssl installed causes dev-lang/ruby-enterprise to be installed on @installed upgrade

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Robin Johnson 2010-09-27 21:39:25 UTC]

# 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.

[Comment 1 Diego Elio Pettenò (RETIRED) 2010-09-28 01:36:39 UTC]

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…

[Comment 2 Hans de Graaff 2011-07-21 08:01:13 UTC]

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"?

[Comment 3 Zac Medico 2011-07-21 16:05:44 UTC]

(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.

[Comment 4 Zac Medico 2011-07-21 16:16:41 UTC]

(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.

[Comment 5 Zac Medico 2011-07-24 08:31:10 UTC]

The @installed thing is the only problem I see here, so I'll re-assign to dev-portage.

[Comment 6 Zac Medico 2011-07-24 08:56:07 UTC]

This is fixed in 2.2.0_alpha47.