virtual/libstdc++ may pull in sys-libs/libstdc++-v3 first, not gcc-3.3 Most of us don't need gcc-3.3. Reproducible: Always Steps to Reproduce: 1. emerge -1pv virtual/libstdc++ in a newly installed system (or without any of sys-libs/libstdc++-v3-bin sys-libs/libstdc++-v3 or =sys-devel/gcc-3.3* installed) 2. portage will choose to install gcc-3.3.6 Actual Results: We need to emerge sys-libs/libstdc++-v3 or sys-libs/libstdc++-v3-bin by hand, and re-emerge virtual/libstdc++ Expected Results: don't need to emerge sys-libs/libstdc++-v3 or sys-libs/libstdc++-v3-bin by hand before emerge virtual/libstdc++
I don't see how any package manager would still do that. I thought the right hack to use was to put the best choice first, and the virtual/libstdc++ ebuild already has that: RDEPEND="|| ( =sys-libs/libstdc++-v3-bin-3.3* =sys-libs/libstdc++-v3-3.3* =sys-devel/gcc-3.3* )" so the only reason for that to happen that I can think of is that sys-devel/gcc comes earlier in the alfabet than sys-libs/libstdc++. :)
he's right, i see the same thing here. maybe gcc gets pulled in because i have gcc already installed in other slots (?) dirtyepic@halo ~ $ emerge -p portage libstdc++-v3 gcc:3.3 [ebuild R ] sys-apps/portage-2.2_rc11 [ebuild N ] sys-libs/libstdc++-v3-3.3.6 [ebuild NS ] sys-devel/gcc-3.3.6-r1 [4.1.2, 4.2.4, 4.3.1-r1, 4.3.3_pre9999, 4.4.0_pre9999] dirtyepic@halo ~ $ emerge -p virtual/libstdc++ [ebuild NS ] sys-devel/gcc-3.3.6-r1 [4.1.2, 4.2.4, 4.3.1-r1, 4.3.3_pre9999, 4.4.0_pre9999] [ebuild N ] virtual/libstdc++-3.3
(In reply to comment #2) > he's right, i see the same thing here. > > maybe gcc gets pulled in because i have gcc already installed in other slots > (?) Right, it's the same issue reported in bug 161953. This behavior is desirable in the vast majority of cases but unfortunately there are a few cases where it's not desirable. The recommended workaround for an undesirable case, such as this, is to mask the unwanted package as shown here: echo '=sys-devel/gcc-3.3*' >> /etc/portage/package.mask
*** This bug has been marked as a duplicate of bug 161953 ***