The vmware-module ebuild provides only one benefit and creates more problems than it's worth. The vmware-modules does allow for a non-interactive rebuild of the kernel modules necessary for VMWare-whatever to run. The vendor provides a minimally-interactive script for rebuilding modules. As a side effect, for users of VMWare Workstation, emerging vmware-modules causes another huge download to take place because vmware-modules uses the VMWare Server tarball instead of the VMWare Workstation tarball with the exact same modules. I find it rather ridiculous that I have to download the Server tarball to get a 2nd copy of some modules that I already have in my Workstation tarball. It is also possible for vmware-modules to be upgraded separately from vmware-workstation, breaking vmware-workstation. Masking every other version of vmware-modules except the one that works with my particular version of vmware-workstation, and maintaining the masking as I upgrade, seems a bit ugly. It seems to me that users who want the single incentive of using vmware-modules could emerge them manually instead of forcing vmware-modules on every vmware user. I am plenty happy with running the minimally-interactive /opt/vmware/workstation/bin/vmware-config.pl script when I upgrade my kernel, but I'm plenty unhappy about having to download two big tarballs when one does the job just fine and it ends up breaking my VMWare Workstation install anyways. Gentoo is about choice. Give me the choice to use vmware-modules or not.
Created attachment 100039 [details, diff] Patch to vmware-workstation-5.5.2.29772.ebuild I've had this same problem, with vmware-server, not vmware-workstation. But here's a patch for -workstation. It modifies the ebuild so that vmware-modules is only pulled in if the binmods USE flag is turned on.
(In reply to comment #0) > Gentoo is about choice. Give me the choice to use vmware-modules or not. This can just get me started, seriously... How about the choice of developers to have maintainable stuff instead of a huge mess that the vmware suite used to be before? You still have a fine choice of sticking vmware-modules into package.provided and maintaining it yourself with interactive scripts; interactive ebuilds suck.
Guys, please calm down. We realize that requiring the vmware-server package to install workstation is not a good option. It affects us as much as it affects you (which is why those ebuilds have not yet been marked as stable). As it turns out, I think we're quite close to a solution, and you could provide productive help if you could please try testing vmware-modules-1.0.0.15-r1 against vmware-workstation-5.5.2.xxxx. The problem would ideally be fixed by vmware allowing separate redistribution of their modules, or actually adopting the vmware-any-any modules so that they only ever use one source, rather than requiring a third party to produce generic modules as quickly as they can. Your second issue of having repeatedly upgrading vmware-modules should not be happening. The packages correctly depend upon ~vmware-modules-1.0.0.X, meaning that only vmware-modules-1.0.0.X and minor revisions (-rY) should be able to fill the dependecy. I believe this is a known portage problem, but I can't recall the exact bug number. I'm marking this as TEST-REQUEST until you've tried up the mentioned ebuilds...
$ equery list vmware [ Searching for package 'vmware' in all categories among: ] * installed packages [I--] [ ] app-emulation/vmware-modules-1.0.0.15-r1 (0) [I--] [ -] app-emulation/vmware-workstation-5.5.2.29772 (0) I don't know exactly what I'm testing. Do they work? Yes Do they require the Server tarball? Nope, huge improvement! Thank you. I'm not really sure how to properly test the dependency issue, but that sounds like a good solution. I still have my doubts this will work exactly right though. After emerging vmware-modules once, its now in my world file, and whenever I do an 'emerge -NDu world', I think it will try to upgrade vmware-modules if an update is available. Thus, vmware-modules versions and vmware-workstation versions can be upgraded separately again. This may also be a non-issue now if vmware-modules isn't using a specific, and possibly incompatible, VMWare Server tarball. Or will this dependency cause a blocker? So when vmware-modules 1.0.0.16 is released and its incompatible with my vmware-workstation-5.5.2-29772 (which may not have the compatible update available yet), do I have to mask vmware-modules until the update to vmware-workstation is available?
Thanks for testing that for me, it was to ensure that vmware-workstation-5.5.2 worked using the latest vmware-modules-1.0.0.15 (which are now built from vmware-any-any sources, rather than the vmware-server ones). Sadly, the way they are built means that 1.0.0.16 will be incompatible with 1.0.0.15, even though they use the same source code (although, even with improperly built modules, there is apparently a way of altering this as runtime, so we may try some tests on that in the future). In a perfect world, vmware-modules wouldn't ever get in your world file (and if you ever need to compile it, you can cause it not to be recorded in your world file by adding --oneshot to emerge). Unfortunately once it's got in there you'll either have to edit the world file manually, or unmerge and remerge the package (with --oneshot). As I say, I think this is a known portage bug, and a search through bugzilla might turn it up. In the meantime, I'm going to mark this bug as FIXED, since the issue with the modules was the excessive download size.
Marking as FIXED as mentioned in the previous comment.
