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

[Matthias G. Eckermann]

Hello Urs, Mike and all,

On 2015-03-10 T 10:17 -0600 Mike Latimer wrote:
> > 
> > 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?

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.

> > I do now have two sorts of VMWare Tools installed,
> > which is really not wanted

I understand the problem.
  
> > In my mind service pack does mean solely security
> > fixes, HW enablement and minor updates, but no
> > architecture, no methods change please. 

In my perspective, the open-vm-tools are (virtual)
hardware enablement, and thus definitely in scope for a
Service Pack, now that we have it available and supported
as an open source package.

> > 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. 

See below for a suggestion.

> > 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).

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.

So long -
	MgE

-- 
Matthias G. Eckermann    Senior Product Manager          SUSE® Linux Enterprise
Phone: +49 30 44315731   Mobile/DE: +49 179 2949448  Mobile/US: +1 917 607 4687
SUSE LINUX GmbH          Maxfeldstraße 5                 90409 Nürnberg Germany
GF: F.Imendörffer,J.Smithard,J.Guild,D.Upmanyu,G.Norton, HRB 21284(AG Nürnberg)