Little inconsistency in the ebuild ;-)
vmware-workstation-5.5.1-19175-r4 requires =~vmware-modules-184.108.40.206 and portage should not upgrade vmware-modules to version 220.127.116.11
This version of VMWare Workstation is not compatible with the latest vmware-modules package as the application returns wrong version message when user try to start/resume a virtual machine.
You're correct, vmware-workstation-5.5.1-19175-r4 requires ~vmware-modules-18.104.22.168 and won't work with later versions, and you're also correct that portage should *not* be automatically upgrading this.
Is this bug that portage is trying to upgrade you to vmware-modules-22.214.171.124? If that's the case please post as much more useful information as you can, such as what emerge command you're trying, any special settings in /etc/portage/package.* relating to vmware, whether you have any overlays that might be influencing vmware, things like that...
I have presently installed on my laptop
which are working fine together. If I pretend to 'emerge world' I have this ...
belgix@edinburgh ~ $ emerge -p world
These are the packages that would be merged, in order:
Calculating world dependencies... done!
[ebuild U ] app-emulation/vmware-modules-126.96.36.199 [188.8.131.52]
Unless I mask manually vmware-modules-184.108.40.206 in /etc/portage/package.mask, portage will upgrade automatically vmware-modules tomorrow morning at my next world update.
Hmmm, that's is weird. I'll have a chat with portage guys and see if they can help me figure it out...
Sorry for the spam, but someone reminded me to check whether you've got --deep or --update set as defaults for your emerge command? Please check your aliases, and also emerge --info to see if they're set anywhere. If so, it might be related to bug #13632...
Created attachment 93502 [details]
Nothing unusual in my emerge --info (see attachment).
I just have ACCEPT_KEYWORD="~x86" and nothing specific to overlays in my /etc/make.conf file.
(TESTED) As expected, adding =app-emulation/vmware-modules-220.127.116.11 in my package.mask file fix my problem.
Created attachment 93506 [details]
Just a question. Can you tell me why line 39 is
in this ebuild ?
Ok, I'm gonna throw this over to the portage guys, to see if one of them can tell whether this is a known duplicate, or something else...
In answer to your question, it's ~<version> rather than =<version> so that it still accepts <version>-r1 and <version>-r2, etc.
Please attach emerge --pretend --debug output for the command that behaves improperly.
Created attachment 93576 [details]
emerge --debug --pretend
should block vmware-modules-18.104.22.168 because
vmware-workstation-22.214.171.12475-r4 requires =vmware-modules-126.96.36.199
Relevant info from the attachment ...
Parent: ebuild / app-emulation/vmware-modules-188.8.131.52 merge
Depstring: x11-misc/shared-mime-info kernel_linux? ( virtual/linux-sources ) kernel_linux? ( virtual/modutils ) sys-app$Candidates: ['sys-apps/sed', 'sys-apps/module-init-tools', 'sys-kernel/vanilla-sources', 'x11-misc/shared-mime-info', '$ ebuild: sys-apps/sed-4.1.5
Exiting... ebuild / app-emulation/vmware-modules-184.108.40.206 merge
(In reply to comment #9)
> Parent: None
> Depstring: app-emulation/vmware-modules
> Candidates: ['app-emulation/vmware-modules']
> ebuild: app-emulation/vmware-modules-220.127.116.11
The "Parent: None" indicates that app-emulation/vmware-modules is in your world set or it's pulled in as a PDEPEND of some package. Most likely, you have it listed in /var/lib/portage/world.
> The "Parent: None" indicates that app-emulation/vmware-modules is in your
> world set or it's pulled in as a PDEPEND of some package. Most likely, you
> have it listed in /var/lib/portage/world.
I see nothing wrong with this. Both packages are installed in my laptop.
(In reply to comment #11)
> I see nothing wrong with this. Both packages are installed in my laptop.
If it's in the world set, you're going to experience bug #13632. There's no need to have it in the world set if it's a dep of another package.
*** This bug has been marked as a duplicate of 13632 ***
Yes, quite similar behavior but w/o using --deep switch. BTW, I will mask vmware-modules-18.104.22.168 in my package.mask to fix this issue.
The "fix" is to remove vmware-modules from your world file. It shouldn't ever be there. I'll be sure to update anything that mentions merging the modules to use --oneshot...
Nevermind... it already says to use --oneshot... =]