Frustration with Support model/RPM versioning of updates
[N.B.: My name isn't 'William Stromberg'. 3 of us share this account; he is the Contracts contact person, so his name is on it.]
I work at a U.S. Government facility that requires us to lock down and "freeze" some of our Linux environments.
As a result, right now we are a shop that is mostly RHEL 5.4, a few RHEL 5.10, a few RHEL 6.3 and some RHEL 6.5 systems (plus a couple of RHEL 7.0 sandboxes).
We are constrained to these choices and upgrading to 5.11 or 6.6 is not an option for us.
I was tasked with upgrading Java in our environment by adding Java 1.7.
(We also have Solaris 10 systems and we'd like to have matching versions if possible.)
I discovered that there are the separate "Thirdparty Oracle Java" RHN channels available so I added them.
When I looked to see what was available for, say, 32-bit RHEL 6.3 and 6.5, I'm presented with these choices:
java-1.7.0-oracle-1.7.0.15-1jpp.1.el6_3:1.i686 Oracle Java Runtime Environment
java-1.7.0-oracle-1.7.0.17-1jpp.1.el6_4:1.i686 Oracle Java Runtime Environment
java-1.7.0-oracle-1.7.0.21-1jpp.1.el6:1.i686 Oracle Java Runtime Environment
java-1.7.0-oracle-1.7.0.25-1jpp.2.el6_4:1.i686 Oracle Java Runtime Environment
java-1.7.0-oracle-1.7.0.45-1jpp.2.el6_4:1.i686 Oracle Java Runtime Environment
java-1.7.0-oracle-1.7.0.51-1jpp.1.el6_5:1.i686 Oracle Java Runtime Environment
java-1.7.0-oracle-1.7.0.55-1jpp.1.el6_5:1.i686 Oracle Java Runtime Environment
java-1.7.0-oracle-1.7.0.65-1jpp.1.el6_5:1.i686 Oracle Java Runtime Environment
java-1.7.0-oracle-1.7.0.72-1jpp.2.el6:1.i686 Oracle Java Runtime Environment
java-1.7.0-oracle-1.7.0.75-1jpp.1.el6:1.i686 Oracle Java Runtime Environment
This underlines something that really bothers me about the current Red Hat support model.
It seems like in general, RPM updates are only produced for the current OS release that is out at the time.
That pretty much screws those of us who can't run 5.11 or 6.6 or 7.0.
Yet there are a few cases - like with 1.7.0_21, 1.7.0_72 and 1.7.0_75 here - where it looks like that 'policy' isn't the case.
Those 3 RPM names are 'generic' and don't indicate what OS they were built on. I presume it's an older version than the current one.
(I don't understand why this policy isn't consistent. Why not always put the OS version into the RPM name, or else why not build all versions against an older revision? Pick one, please.)
So if I'm sitting here wanting to upgrade Oracle Java on one of my 6.3 systems, which version do I choose?
Do I choose 1.7.0_15, because I know it was built on RHEL 6.3?
Or do I choose 1.7.0_75, because the RPM name says "el6" and not "el6_6", so maybe it was built against an older version like 6.3 - or even earlier?
Similarly for RHEL 5.x. The 1.7.0_72 and 1.7.0_75 RPMs were built on RHEL 5.11. Do I dare install 1.7.0_75 on 5.10 and pray it doesn't break? What about on RHEL 5.4?
Or do I fall back to the 'safe' 1.7.0_65 that I know was built on 5.10 and will be compatible with it? Similarly for 5.4 - do I use the 'safe' 1.7.0_21?
Before someone says "Oh, you can install any of these on any RHEL 5/6.x machine!", I don't believe it.
Why? Because I took the most recent "Critical" Firefox 31.5.0 release - built on 5.11 - and rebuilt the SRPM on 5.10. That worked.
But when I tried to rebuild the exact same SRPM on 5.4, it failed in at least 3 places. So what will happen when the compiled 5.11 binaries run those same bits of code on 5.4 that builds on 5.10 and 5.11, but does not build on 5.4? I'd expect "undefined behavior" at best, and a crash at worst.
I never assume backwards compatibility with binaries. So I would not install a RHEL 5.11-built RPM on a 5.4 system, much less a 5.1.
I would really appreciate someone (preferably from Redhat) straightening this out for me.
Thanks in advance,
Greg
