[sles-beta] SLES11-SP4 beta2 x86_64 - VMware Tools Again ...

[Mike Latimer]

On Tuesday, March 10, 2015 02:54:24 PM urs.frey at post.ch wrote:
> Hi all
> 
> Until now SLES11-SP3 hat no open-vm-tools included, fact.

That's correct.

> Now when I do an online update from SLES11-SP3 to SLES11-SP4 using zypper
> --non-interactive dist-upgrade --auto-agree-with-licenses I find
> open-vm-tools installed
 =================
> Warning: You are about to do a distribution upgrade with all enabled
> repositories. Make sure these repositories are compatible before you
> continue. See 'man zypper' for more information about this command.
> Loading repository data...
> Reading installed packages...
> Computing distribution upgrade...
> 
> The following NEW packages are going to be installed:
>   crash-eppic libevent-1_4-2 libgmodule-2_0-0 libiptc0 liblzmadec0
> libnfnetlink0 libvmtools0 libxtables9 lzma nfs-client nfsidmap
> open-vm-tools release-notes-sles rpcbind

That was not expected (at least from my side), and is certainly not desirable. 
Can of you open a service request so we can get a bug to track this?

> I do now have two sorts of VMWare Tools installed, which is really not
> wanted
 
> vtsteh:~ # rpm -qa | grep -i vm | grep -i tools
> pst-VMwareTools-9.4.11-2400950
> libvmtools0-9.4.6-1.1
> open-vm-tools-9.4.6-1.1
> 
> The problem is now, that within a simple service pack update absolutely NO
> architecture change must be done. Else there should also be updates to 
> perl 5.16, Apache 2.4, Tomcat 7, java 8, php5.5 etc. 
> So in my mind SLES11 should keep being without open-vm-tools and let us keep
> the original ESX VMwareTools
 
> OK, I could write a script to remove the previously installed ESX Tools,
> change all system settings back to native and let the door open to
> open-vm-tools. But this is lot of engineering reverting and has nothing to
> do anymore with a simple service-pack. 
> BUT: 
> how much can we then say "it is only a service-pack update".
> In my mind service pack does mean solely security fixes, HW enablement and
> minor updates, but no architecture, no methods change please. No automated
> installation of new things where one has to reverse-engineer to know where
> it comes from and find an own way to work around. 
> So please think the subject with these open-vm-tools over.
> And if you come to a result, that open-vm-tools is a must, then declare
> SLES11-SP4 as a new release with major changes please. Not only a
> service-pack update

The inclusion of open-vm-tools was intended as a convenience change - not a 
challenge to overcome.  ;)  I'll finish my testing and we will either drop the 
package, or fix the dependency so it is not automatically installed (which was 
the original intent).

Thanks again for making me aware of this.

-Mike