[sles-beta] SLES11-SP4 beta2 x86_64 - VMware Tools Again ...
Mike Latimer
mlatimer at suse.com
Tue Mar 10 21:39:02 MDT 2015
Hi Matthias,
On Wednesday, March 11, 2015 02:59:40 AM Matthias G. Eckermann wrote:
> Well. In my view, this behaviour is consistent and
> correct, and here is why:
>
> 1. An Upgrade from SLES 11 SP3 to SLES 11 SP4 should
> deliver an identical result as a fresh installation
> of SLES 11 SP4.
>
> 2. Automatically installing the open-vm-tools is
> recommended in a fresh installation, as only this
> way we get the best user experience.
>
> 3. If we include the open-vm-tools and install it,
> if a VMware environment is found during an initial
> installation, this should also be done during an update.
While the above comments make sense, we were specifically concerned about
residual files which might conflict with open-vm-tools components. Based on
these concerns, the original intent for SLES11SP4 was to make installing open-
vm-tools a choice - rather than an automatic installation. (See FATE#318106,
comment #10). (We also specifically decided that removing VMware tools prior to
the open-vm-tools package was not a safe option.)
The automatic installation of open-vm-tools is due to a 'Supplements'
statement in the open-vm-tools package which matches a VMware pci device ID. I
made this change for SLES12, and removing it for SLES11SP4 should "fix" it (if
we decide to go that route).
> I am afraid that solution contradicts the consistency
> requirement described in the beginning of this E-Mail.
>
> My proposed solution is to document the new availability
> of the open-vm-tools in the release notes and add also add
> an autoyast snippet there, how to prevent the
> installation, if the old vmware tools are installed.
This may be a possibility, but it would only impact autoyast installations. Is
this worth the effort - at the risk of breaking non-autoyast based upgrades?
Thanks for the comments,
Mike
More information about the sles-beta
mailing list