On 04 September 2014 00:45, David Nalley [da...@gnsa.us] wrote: > On Wed, Sep 3, 2014 at 7:40 PM, Alex Brett <alex.br...@citrix.com> wrote: >> To expand on this a little bit - in RHEL 6.3 if you have both Java 1.6 and >> Java 7 installed, the default behaviour with the alternatives mechanism >> makes 1.6 the default Java instance (you can manually set 1.7 as the >> default, but this is an extra step). This means that the management server / >> KVM agent then fail to work. >> >> In 6.5 if you have both then by default Java 7 is used, and all works fine >> (not sure about 6.4 or 7, I've not tested them). >> > > Perhaps we add a Conflicts with java 1.6 - it would be somewhat ugly, > and if you run into it you would need to know to yum remove, but that > would keep you from having an installation at all rather than > expecting it to work and trying to debug. >
I'd have thought this would prove problematic over upgrade - as you'd have a conflict that the new version would need to have 1.6 removed, but you can't do that without removing your old version first. There's also the issue of if the user wants to have both around for other tools they're running on the same machine. Some solutions that don't break upgrade that I can see are: * Rayees change in the review to point directly at Java 7, with the caveat that this might have some cross platform issues * Somehow automating the alternatives mechanism, i.e. doing a check as part of management server startup somewhere that if the default Java is 1.6, setting it to be Java 7 (which we know should be installed by the RPM dependencies) - a little ugly as we are changing a user's default underneath them, and may also have cross platform issues * Require use of 6.5 (or possibly 6.4 if the version that has works) instead of 6.3 - we do already say to install all hotfixes etc, which in theory means people should be there (yum update / upgrade on a 6.3 system will make it 6.5+), though I think we know in practise a lot of users aren't as they prefer to keep things at a stable state or only apply very specific updates. I guess this would be done by specifying a minimum Java version required that is only in the appropriate release or later. * Don't actually block it in the RPM, but check in the init script what version of Java we're going to end up picking up, and if it's 1.6 fail with a clear error message suggesting the user changes the default - still means the management server / agent won't start after upgrade, but is at least a reasonably easy fix. Alex
