Bugzilla Bug 174509

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 an attachment (id=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.