Bug 174509 – If all ebuilds are gone Portage doesn't consider installed stuff as providing a virtual

• Product: Portage Development
• Status: CONFIRMED ---

[Description Petteri Räty (RETIRED) 2007-04-13 19:27:02 UTC]

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)

[Comment 1 Petteri Räty (RETIRED) 2007-04-13 19:27:53 UTC]

Created attachment 116184 [details]
emerge --debug output

[Comment 2 Jakub Moc (RETIRED) 2007-04-14 10:30:37 UTC]

Hmmm, looks like another variant of Bug 173366; old- and new-style virtuals' handling is weird in the same way.

[Comment 3 Zac Medico 2007-04-16 17:09:34 UTC]

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

[Comment 4 Zac Medico 2007-04-16 17:10:08 UTC]

*** Bug 173366 has been marked as a duplicate of this bug. ***

[Comment 5 Zac Medico 2007-10-07 21:41:05 UTC]

*** Bug 195028 has been marked as a duplicate of this bug. ***

[Comment 6 David Barnett 2007-10-07 22:59:00 UTC]

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?

[Comment 7 Zac Medico 2007-10-07 23:26:06 UTC]

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

[Comment 8 Jakub Moc (RETIRED) 2008-01-22 09:10:25 UTC]

*** Bug 206978 has been marked as a duplicate of this bug. ***

[Comment 9 Zac Medico 2009-02-02 02:12:14 UTC]

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.