open-vm-tools (CLI tools) recommends gui tools

[Hans-Christian Prytz]

Binary package hint: open-vm-tools

Ubuntu 10.04,

Currently open-vm-tools (and open-vm-dkms) reccomends open-vm-toolbox which results in apt wanting to install all kinds of X11 packages.
This really makes no sense since the package is describes as CLI tools. Also on a server this would install a lot of packages that are not needed, and are a potential security risk.

The solution suggested in bug #391224 (https://bugs.launchpad.net/ubuntu/+source/open-vm-tools/+bug/391224) works when installing manually, but breaks down when using automated systems like puppet.

The recommendation should be opposite, open-vm-toolbox should recommend open-vm-tools.

[Chris Bainbridge (chris-bainbridge)]

I just filed a dupe of this at bug #628039

open-vm-tools should either not recommend toolbox, or there should be an open-vm-tools-nox package which does not recommend toolbox. The description needs updating.

[Clint Byrum (clint-fewbar)]

Hi Hans, Chris, thanks for taking the time to file these bug reports and help us make Ubuntu better.

Agreed 100%, this is a set of tools that are infinitely usable without toolbox. In fact, open-vm-toolbox already does depend on open-vm-tools. I think the solution may be to drop open-vm-toolbox to a Suggests.

Marking status as Confirmed, Importance as Wishlist.

One thing, we probably won't be able to update the stable releases of Ubuntu with this, as some people may be depending on the current behavior, but we can certainly do it for Oneiric and later.

[Oliver Brakmann (obrakmann)]

Thanks Clint!

I don't know if anybody has noticed this yet, but this problem exists in Ubuntu only. The same package in Debian merely suggests: open-vm-toolbox.

Oh, and the changelog gives the reason why: LP #391224. I guess we have conflicting interests here.

Personally, I'd argue for dropping the recommends: back to a suggests: as well.

[Clint Byrum (clint-fewbar)]

Excerpts from Oliver Brakmann's message of Fri Jun 10 21:50:55 UTC 2011:
> Thanks Clint!
>
> I don't know if anybody has noticed this yet, but this problem exists in
> Ubuntu only. The same package in Debian merely suggests: open-vm-
> toolbox.
>
> Oh, and the changelog gives the reason why: LP #391224. I guess we have
> conflicting interests here.
>
> Personally, I'd argue for dropping the recommends: back to a suggests:
> as well.

Good point Oliver.

With software center, I think a strong case can be made that there is
no good reason anymore. Searching for 'vmware' or 'vmware tools' or
'vmware guest' only shows toolbox, because software center defaults to
showing packages with a .desktop file. Synaptic and aptitude are both for
expert users who should be able to see why they didn't get GUI because
it clearly says that it is the command line tools.

[David Glover (me-davidglover)]

You used to be able to work around this "--no-install-recommends", but as of 11.10 that no longer works. It's no longer possible to install open-vm-tools without also installing x11.

I think this deserves to be upgraded to bug, rather than "wishlist".

[Oliver Brakmann (obrakmann)]

Oh wow. That's because the GUI package has been merged with the CLI-only package as of Oneiric. And again, this change is in Ubuntu only, Debian still does The Right Thing(tm). What the hell?

Can we pleased get this fixed for the next LTS?

[Hans-Christian Prytz (hcpr)]

I second this.

This seems like a very strange thing to do.

Please fix this so we don't need to maintain a separate package locally.

[Shane Madden (madden-shane)]

See bug #776103 (and my comment on it). The toolbox package was removed, so X11-related components (and all the dependencies that come with them) were merged into this package - the description for which is still "(CLI tools)".

Currently, this package is not usable on server systems which must not have X11 installed. Definitely would be nice to see this fixed for 12.04..

[Nate Muench (Mink) (n-muench)]

@Shane,

I assume your referring to the dependencies of: xauth, xserver-xorg-input-vmmouse, and xserver-xorg-video-vmware. I don't know if xdg-utils is a X-related Package or not.

But I have 2 options, which could use input. And for the record, I'm going to add to my August release proposal (which will be a brand new one)
1) Create a package called "open-vm-tools-gui," which will include only X-related packages, and depend on open-vm-tools. So it technically will be a dummy file (I think). I don't know how to have the package auto-install if it detects that Ubuntu isn't running a server. This option is also troublesome, I think you know why. If this option chosen, I might create a proposal for Oneiric-Proposed.
2) I can't remember my original #2, but here's an alternate. Approve my proposal (which one has be added for Precise), so that we have something to work with. Said proposal can be found here: https://code.launchpad.net/~n-muench/ubuntu/oneiric/open-vm-tools/open-vm-tools-august.merge

[Shane Madden (madden-shane)]

@Nate,

Yeah, a number of the added depends and recommends lead back to X stuff. Here's the added ones that do, as far as I can tell:

- Requires:
libgdk-pixbuf2.0-0
libgtk2.0-0
libgtkmm-2.4-1c2a
libice6
libx11-6
libxcomposite1
libxext6
libxi6
libxinerama1
libxrandr2
libxss1
libxtst6
- Recommends:
xauth
xserver-xorg-input-vmmouse
xserver-xorg-video-vmware

I think a separate package is probably how this needs to end up, I agree. I'm not sure if it could be purely a dummy package - would any of this stuff brought in from the old toolbox package cause problems on a system with no X11 present? (Heck, if they don't, then a single unified package would work just fine.)

/etc/vmware-tools/xautostart.conf
/etc/xdg/autostart/vmware-user.desktop
/usr/bin/vmware-xdg-detect-de
/usr/lib/open-vm-tools/plugins/vmusr/libdesktopEvents.so
/usr/lib/open-vm-tools/plugins/vmusr/libdndcp.so
/usr/lib/open-vm-tools/plugins/vmusr/libresolutionSet.so
/usr/lib/open-vm-tools/plugins/vmusr/libunity.so

The best 'shape' of that eventual solution as far as packages and their names, I'm not sure on.

open-vm-tools for CLI // open-vm-tools-gui for GUI
open-vm-tools for CLI // open-vm-toolbox for GUI
open-vm-tools-cli for CLI // open-vm-tools for GUI
open-vm-tools-cli for CLI // open-vm-tools-gui for GUI
open-vm-tools-nox for CLI // open-vm-tools for GUI

I'm really not sure what naming scheme would be the most Ubuntu-appropriate, but I'd personally have no complaint with any of those variants.

[Nate Muench (Mink) (n-muench)]

First of all, open-vm-toolbox, is a transitional package. The GUI version no longer is in the program/package, only the CLI/cmd version still exists.

I thought of a possibly better solution, which may be a win-win scenario.

If we split up the packaging for GUI and CLI version, it might cause headaches for a lot of people (including myself).

I am going to assume that most people who use Ubuntu on a VMware product will be using the Desktop version, not the server. Although, some of them use the Tools that comes with the program. Where I go to college, for the Linux I class they now use Ubuntu (they used used Fedora, when I took the class), the GUI version. For Linux II, they use SUSE Enterprise Server, GUI version, most of the time.

SOLUTION: Keep the open-vm-tools package as it is. But a create a new source packaging, just for the people who run the server/CLI version of Ubuntu.

If I had to do this on my own (like I did for what's in the Oneiric repo), with limited knowledge of this stuff (although turning open-vm-toolbox into a transitional package was a learning experience, and I'm more wiser). I personally would create a new source package, and just strip all the GUI stuff out of it, and rename the packages. Doing this would keep the package stable (at most), I think.

I personally want a second opinion from either Evan, Serge, or Dave (the latter 2 have sponsored my uploads (for Maverick and the current Oneiric/Precise packages)).

[Shane Madden (madden-shane)]

> I am going to assume that most people who use Ubuntu on a VMware product will be using the Desktop version, not the server.

Sorry, but this is not the case at all - VMware's primary products are their server offerings, and those of us running linux servers outside of an education setting do so overwhelmingly with no desktop environment.

While it's obviously up to Canonical and the community, I don't believe that making the server distribution a second class citizen by forcing use of a source package is the right direction to take just to assuage some potential confusion between CLI and GUI packages. As Client pointed out in June, Software Center will happily point the user to packages containing a .desktop file by default - what's wrong with that?

These changes, as well as Evan's in bug #391224, seem to have centered around the assumption that VMware Tools is primarily for GUIs. I'd like to urge you to look outside of your own use cases, please.

[David Glover (me-davidglover)]

I agree with Shane. Desktop users are far more likely to install the official tools anyway. It's people using servers (in our case, an ESX cluster) where the open vm tools become very useful.

[Chris Bainbridge (chris-bainbridge)]

Yes, when I originally opened a bug on this we were using headless rackmount servers. I would imagine that is the dominant use case.

[Nate Muench (Mink) (n-muench)]

You were thinking of VMware Server, while I was thinking VMware Workstation/Player/Fusion. Sorry about that.

@David

Normally, the open source version of the tools are useful for the testing phase of the release cycle, like Precise is going to be shortly (for Alpha 1). The is because the newer kernel, that will eventually be supplied in the release, will fail to compile with the official Tools.

But yes, most users would use the Official Tools.

[Shane Madden (madden-shane)]

So, is there any chance of getting this fixed before 12.04?

[Nate Muench (Mink) (n-muench)]

Yes, I'm the process of doing new packaging. I'm syncing with Debian (mostly), and I'm using the removed open-vm-source pkg to return open-vm-toolbox to full package status.

I didn't know what Debian was going to do with the removed Toolbox GUI, since they're keeping it, I'm going to return it.

Expect new packaging by some time around the release of Alpha 2. I just to add the December release to my working branch, test it, and create the proposal for merging (hopefully properly this time).

[Shane Madden (madden-shane)]

Great, thanks a lot for all your hard work on this! Appreciate it!

[Launchpad Janitor (janitor)]

This bug was fixed in the package open-vm-tools - 2011.12.20-562307-0ubuntu1

---------------
open-vm-tools (2011.12.20-562307-0ubuntu1) precise; urgency=high

  * Merge latest upstream git tag. Fixes building on Precise
    (LP: #898289, LP: #905612)

  * Items merged from Debian unstable:
    - debian/control:
      + open-vm-tools recommends open-vm-dkms. (LP: #598933)
      + open-vm-tools now suggests open-vm-toolbox. (LP: #604998)
    (From 2011.08.21-471295-1 release)
    - Updating maintainer and uploaders fields.
    - Removing vcs fields.
    - Removing references to Daniel's old email address.
    - Updating years in copyright file.
    - Updating to standards version 3.9.2.
    - Updating to debhelper version 8.
    - Switching to source format 3.0 (quilt).
    - Removing manual chrpath setting.
    - Removing exclusion from plugins from debhelper shlibs.
    - Rediffing kvers.patch.
    (From 2011.09.23-491607-1 release)
    - Marking binary architecture-dependend packages as linux and kfreebsd
    only.
    - Removing liburiparser-dev from build-depends as upstream dropped
    unity support.
    - Building with libproc-dev on amd64 again.
    - Dropping disabling of dnet support.
    (From 2011.09.23-491607-2 release)
    - Adding doxygen to build-depends for api documentation.
    - Adding libcunit1-dev to build-depends for test suites.
    - Minimizing rules file.
    - Adding open-vm-tools-dev package, containing only the api
      documentation for now.
    (From 2011.09.23-491607-3 release)
    - Sorting overrides in rules alphabetically.
    - Compacting copyright file.
    - Adding udev rule to set timeout for vmware scsi devices
    (From 2011.12.20-562307-1 release)
    - Adding patch to correct typo in upstreams dkms configuration

  * Remaining Changes:
    - Remove Stable part of version numbering.
    - debian folder:
      + Re-added open-vm-dkms.postinst & open-vm-dkms.prerm.
        * Allows dkms modules to compile upon installation.
    - debian/control:
      + Re-add open-vm-source and make into a transitional package
        for open-vm-toolbox.
      + Return dependancies that were moved to open-vm-tools back to
        open-vm-toolbox.
    - debian/rules and debian/open-vm-toolbox.lintian-overrides:
      + Make vmware-user-suid-wrapper suid-root
    - debian/rules:
      + Added CFLAGS field with -Wno-deprecated-declarations
        * Will suppress issues with glib 2.31 or later.
      + Add line to copy vmware-xdg-detect-de into place.
      + Install vmware-user.desktop through toolbox package.
    - debian/open-vm-tools.init:
      + Re-add 'modprobe [-r] vmblock'.
      + Add 'modprobe [-r] vmxnet'.
        * Incase it's not loaded during boot.
      + Remove and re-add pcnet32 module
        * Will be done before (remove) and after (readd) vmxnet module
          is added.
        * If vmxnet doesn't exist (aka modules fail to build), pcnet32 can be
          still used for network connectivity.
        * Workaround until a better fix can be done.
    - Re-add gnome-session to debian/local/xautostart.conf
    - Manpages removed (from debian/manpages):
      + vmmemctl.9
      + vmxnet3.9
      + Remov...

[tom_major (tom-major)]

Great work, can anyone say when the updated package is available through the repository?