I've already spoken to Mike Autry about this, and he asked me to put my patch here and have it assigned to vmware@gentoo.org. Reasoning: the Network Editor component of Workstation requires scripts provided in libgksu, and fails without them. Patch, including new -r1 ebuild, attached.
Created attachment 181682 [details, diff] Patch containing new ebuild, ChangeLog entry, etc.
Ok, I've made this change in the main tree, although I haven't done a version bump. I may do one when I have more time (I need to do a clean out of all the old/masked versions at the end of this month). I'll leave this bug open until it gets sorted properly...
OK. I'd do a version bump eventually so that people are sure to have the dep installed. The reinstall was quite painless. Thanks!
Can this be made into use flag? I don't have gnome installed so this pulls a several packages (dbus, libtasn1, libgtop, orbit, gconf, gnome-keyring, sudo, libgksu) and you don't really need this functionality (you can just run vmware-netcfg as root).
I'd second the request to make libgksu an optional dependency.
I don't think this should be optional, or else a big fat warning should appear on install. Not everyone knows how to use vmware-netcfg, and the error message displayed when trying to open the Network Editor without it is not very helpful. The end user just sees a broken application. Here are some ideas. I'd recommend #1 or #2 but not #3: 1) Keep it as is...yes, this is VMware's fault, but VMware not understanding how to do things properly on Linux is nothing new. 2) Don't use a gnome USE flag, as this isn't optional GNOME integration but an actual dependency of a non-optional portion of the runtime code. (I know you don't have to use the editor, but it doesn't check to see whether the support exists before failing, it just fails, so it's not optional in the way a plugin would be.) Instead use a local USE flag, enabled by default, called networkeditor or some such thing, and display a warning at the end of install if it is not toggled. 3) Use the gnome USE flag but display a warning at the end of install if it is not toggled.
Vmware comes with its own internal copy of libgksu. As has been policy for the vmware herd, we always try to install system packages where possible even if vmware ships them (particularly for security sensitive libraries). These are not optional, because they're a part of the vmware product (and because they're effectively installed already, you just don't see them). As such, we won't be making gksu optional, even if its not used often. Hopefully, in the future, we'll remove the pre-compiled vmware libraries that aren't necessary and rely exclusively on the system libraries. Until then, it should be treated in much the same way as any of the other X or gtk+ dependencies that vmware-workstation already has.
I'd like to second (well, third, I guess) the request to make the libgksu dependency optional. Removing or disabling functionality normally provided by a package is hardly something new to Gentoo; after all, as I understand it, that's the primary purpose of USE flags. As in Jeff's second suggestion in comment #6, a "networkeditor" or similar USE flag (with an appropriate warning on install) ought to be sufficient. As a side note, vmware-workstation-6.5.2.156735 no longer includes libgksu in RDEPEND. Is this intentional? Inquiring minds would like to know, lest they purge a dozen or so packages only to have to reinstall them later. (:
Don't bother purging the packages, libgksu was left out as an oversight but I've just added it back. Please see comment 7 as to why it's a required dependency.
Mike, I accept your policy statement made in Comment 7, which to paraphrase says "VMWare should look and behave in Gentoo exactly as it does in other distributions". I think most would agree that this is the minimum starting position. However, I think there is room for doing more than this minimum. Without actually adding any new functionality, my many Gentoo systems have systematically grown over the years, despite my best attempts at adding -use-this and -use-that to package.use files. I have the impression this is all in the name of the "it just works" expectation that Ubuntu has created. Users want distributions that, well, just work, without the need for patient web searching to find just the right combination of settings to add to that obscure file in /etc. For binary distributions like Ubuntu this is great. For source distributions like Gentoo, created precisely to allow for maximum choice, this seems a little odd. For me, Gentoo is the distribution of choice because it allows me to install packages in ways that other distributions don't. If all I want is a working VMWare that looks just like it does in Redhat or Debian or Ubuntu, then surely I'll choose one of those distributions? I choose Gentoo because I want more control -- more choice. I appreciate the time it takes for you, and the very many other Gentoo devs, to create and maintain the broad range of packages available in the distribution. I accept that adding use flags to allow this or chop out that does not come without a cost. If it is a time issue, then this is the end of the matter -- I'd rather we have the latest versions in portage than more control over the installation. Perhaps this is really a more general discussion about Gentoo, and its core philosophy. If choice continues to be eroded in the name of simplicity and support, then I'm not sure what the Gentoo advantage really is. The ability to alter and influence the way in which a package is built -- its constituents, its dependencies, the way in which it is compiled, choices sometimes even beyond those allowed by its authors -- is the essence of Gentoo. Again, many thanks for supporting VMWare in Gentoo. Anthony.
I agree with Anthony's well-written sentiments -- including the thanks for supporting VMware, which I know is not an easy task. I likewise think it would be nice to see some more granularity in dependencies and feature selection, but on the other hand, as libraries and APIs grow more complex and more deeply layered, that may be asking a bit much of the volunteers who maintain the ebuilds. (And it's probably unreasonable to ask application authors to avoid high-level libraries and reinvent the wheel just to save us a few extra package installations.) I just wanted to note here that I looked into the VMware distribution a bit more, and it looks like gksu is fairly deeply entwined in the current product; aside from the network editor, it seems to also be used for things like the Unity feature that lets you move a guest window to the host window manager. Exactly how it's used I haven't checked, but it may be safer after all to leave the unconditional dependency on libgksu as is.
Anthony, I understand your concern about the philosophy of Gentoo and whether this dependency goes against it, but it's a little out of place in this particular circumstance. This isn't a matter of things like integration "just working" -- for instance, pinentry with ssh-agent. It's a matter of parts of workstation actually failing. The code isn't well written to check whether gksu exists. You can't disable the menu function to open the network editor or to disable the other features that depend on it. They are simply options that are always presented to the user regardless of whether gksu is there or not, and fail with totally unhelpful error messages if the required libraries are missing. It is telling that VMware normally ships gksu in its package -- it means they consider it a required dependency, and as Andrew noted, it seems to be both expected in their software and tightly integrated with it. In this particular instance, the packagers (as normal) stripped out the dependency in favor of a system version that they can know has appropriate security patches, etc. -- but they simply forgot to actually add the dependency into RDEPEND after doing the stripping. In other words, this isn't a new optional dependency -- it's something that should have been there from the start and was simply forgotten.
