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 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? So if I'm sitting here wanting to upgrade Oracle Java on one of my 6.3 systems, which version do I choose?ĭo I choose 1.7.0_15, because I know it was built on RHEL 6.3? 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.) (I don't understand why this policy isn't consistent. I presume it's an older version than the current one. Those 3 RPM names are 'generic' and don't indicate what OS they were built on. 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. That pretty much screws those of us who can't run 5.11 or 6.6 or 7.0. It seems like in general, RPM updates are only produced for the current OS release that is out at the time. This underlines something that really bothers me about the current Red Hat support model. When I looked to see what was available for, say, 32-bit RHEL 6.3 and 6.5, I'm presented with these choices: I discovered that there are the separate "Thirdparty Oracle Java" RHN channels available so I added them. (We also have Solaris 10 systems and we'd like to have matching versions if possible.) I was tasked with upgrading Java in our environment by adding Java 1.7. We are constrained to these choices and upgrading to 5.11 or 6.6 is not an option for us. Government facility that requires us to lock down and "freeze" some of our Linux environments.Īs 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).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |