RHEL : yum update without migrating to point releases
 

Hi

I installed RedHat 6.3, and I want to install all of the latest updates after the install but I don't want to update to RHEL 6.4.

At first I tried this, but it updates to 6.4.
Then I re-staged 6.3 and ran the following which also updated the system to 6.4.
I read in a previous post, that this is only possible with Satellite Server by creating a custom channel, and only adding the package updates that you require.

Is this still the case with RHEL 6.3 ?

Thanks

the point releases are only baselines. it makes no sense to want to stay on a single version. If someone is telling you otherwise, they're wrong. Up to date is up to date. a new package released for 6.4 will be the same security update for a base 6.0 release.

Thanks for your reply. My major concern is in terms of software compatibility.

Say for arguments sake that HP DataProtector (*) is supported and tested with RHEL 6.3, RHEL 6.4 is released which introduces some new features changing the code path, preventing the software from running, then i'm stuck because the vendor does'nt support his software with RHEL 6.4.

I understand your argument that the major releases should be supported by vendors, but I think in reality they will dive into the point releases when it comes to compatibility.

* Replace with any other vendor software.

this would really be HP not appreciating / clarifying the exact position they have on the point releases. Of course though, they can clearly only test what is available at a point in time, but they can't ever expect you to not keep a system up to date, and I'd never think it likely that they'd not support a 6.4 system.

The only way to do that is to edit the files in /etc/yum.repos.d and change each instance of "$releasever" to "6.3", but doing so will cut you off from all updates, including security updates. You might as well just turn off updates entirely.

that is a bit "odd"
red hat dose not change major versions of programs in any minor upgrade

now the securityupdates for 6.3 included xorg 1.13 ( moved from 1.10 to 1.13 )
this WILL break some very , very,very old software ( example the dead and unsupported Nvidia 96.run driver)
and rhel6.4 will have xorg 1.13

so what exactly ! is going to cause your HP software to stop working

unless you need hardware compatibility for 12+ year old hardware there really is nothing in 6.4 to "kill" some HP program .

It's been my experience of working with Solaris in particular that OS update releases sometimes add/change/remove features changing the code path and therefore occasionally breaking certified applications that run on particular releases.

If you ask me what exactly has changed between 6.3 and 6.4 from RedHat at the source code level, I cannot answer that question, but if an application stops functioning due to an OS update, and as was pointed out earlier, that the vendor commits to support their app on RHEL 6.x, then that application vendor should fix their software. This is a good point.

In a perfect world, you would have an engineering or test environment, where you can test production application software with the OS update to confirm that it continues to work.

The HP software was just an example of one software & vendor. Maybe I should of wrote xyz software.

If anyone has a different opinion or personal experience, then i'd be very keen to hear it, even if it's different to my own :-)

I agree with all the above advice.
All comments below relate to RHEL...

Minor pt releases are just arbitrary lines in the sand; most (all?) serious vendors commit to supporting major release versions.
Obviously if you update before they get a chance to test, you might(!) get an issue, although minor pt releases (as above) rarely break stuff.

Yes, you should definitely have a test system.

If you're really paranoid, either turn off updates altogether, or at least wait until you get the ok from the vendor(s) in question.

HTH :)

At what point during the yum update does RHEL 6.3 become RHEL 6.4 and how.

the version is defined in the redhat-release package. So when that gets updated, so does the system version number.

What I can't show you though, from googling around, is a chain of dependencies that crystallizes what defines the version number being ligitimately associated with certain versions of new packages. I would expect to see the redhat-release package depends on a certain kernel and glibc version, but I don't see that link anywhere on line.

What acid_kewpie said ... :)
If you REALLY care about the fine detail (ie how they decide to change the num), you'll have to phone RH support and ask.
As you sound like you've got a RH subscription, it may even be in the Knowledgebase if you login to redhat. It could be fairly arbitrary eg like Daylight Savings switches are roughly predictable, but the decision on the actual date is a political one...