Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 338959 - virtual/ruby-ssl: Having any version of ruby-ssl installed causes dev-lang/ruby-enterprise to be installed on @installed upgrade
Summary: virtual/ruby-ssl: Having any version of ruby-ssl installed causes dev-lang/ru...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords: InVCS
Depends on:
Blocks: 144480
  Show dependency tree
 
Reported: 2010-09-27 21:39 UTC by Robin Johnson
Modified: 2011-07-24 08:56 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 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) gentoo-dev 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 gentoo-dev 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 gentoo-dev 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 gentoo-dev 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 gentoo-dev 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 gentoo-dev 2011-07-24 08:56:07 UTC
This is fixed in 2.2.0_alpha47.