22:03 < jimmytango> Betelgeuse: thanks for all the help earlier... 22:04 < jimmytango> Betelgeuse: sucks that it was my end. I still find that weird that if the ebuild is gone, then portage forgets you have it installed. 22:04 < jimmytango> Betelgeuse: I thought that was what the /var/db stuff was for. The problem was sun-jai-bin bringing in sun-jdk when jrockit is installed: These are the packages that would be merged, in reverse order: Calculating dependencies ....... done! [ebuild N ] dev-java/sun-jai-bin-1.1.2.01-r1 2,543 kB [ebuild N ] dev-java/sun-jdk-1.5.0.11 USE="doc -X -alsa -examples -jce -nsplugin" 48,437 kB [ebuild N F ] dev-java/java-sdk-docs-1.5.0-r1 45,109 kB Total: 3 packages (3 new), Size of downloads: 96,088 kB Fetch Restriction: 1 package (1 unsatisfied)
Created attachment 116184 [details] emerge --debug output
Hmmm, looks like another variant of Bug 173366; old- and new-style virtuals' handling is weird in the same way.
(In reply to comment #2) > Hmmm, looks like another variant of Bug 173366; old- and new-style virtuals' > handling is weird in the same way. Yes, it's essentially the same situation. There should at least be a warning if different package is selected over an installed package due to lack of an ebuild or masking of an ebuild.
*** Bug 173366 has been marked as a duplicate of this bug. ***
*** Bug 195028 has been marked as a duplicate of this bug. ***
There are actually two problem scenarios. One is pulling in a package you don't need when the virtual is already satisfied, and possibly linking to the wrong package. The second is actually failing out because all other dependencies are genuinely masked. I would give portage the benefit of the doubt on the first issue because it thinks it's found a workable solution and it just jumped the gun a bit on the decision, but in the second scenario it actually fails out when there is no real dependency problem. It's interesting also that it looks like the dependency installed doesn't need to be the same version as the ebuild to be considered met. For instance, I had "|| ( dev-lang/python-2.5 >=dev-python/pysqlite-2.3.4-r1 )" with pysqlite-2.3.4-r1 installed, and if I unmasked pysqlite-2.3.5, which did still have an ebuild but wasn't installed, portage didn't try to pull in pysqlite-2.3.5. Having 2.3.4-r1 installed but masked and 2.3.5 unmasked but not installed was enough. By way of a workaround, is there any way to make 'emerge -u --deep' work for everything else without giving in and installing the other dependency?
(In reply to comment #6) > By way of a workaround, is there any way to make 'emerge -u --deep' work for > everything else without giving in and installing the other dependency? At the moment the best you can do is to put the unwanted package in /etc/portage/package.mask so that it will never be considered.
*** Bug 206978 has been marked as a duplicate of this bug. ***
This is in direct conflict with the behavior from bug 252167 which assumes that packages that don't have corresponding ebuilds are undesirable for some reason. So, we'll have to add an option to control this behavior to suite different people's tastes.
