On 05/10/2012 04:49 AM, Peter Kjellström wrote: > On Thursday 10 May 2012 03.58.17 Johnny Hughes wrote: >> On 05/10/2012 01:46 AM, Peter Kjellström wrote: >>> On Thursday 10 May 2012 17.36.07 Gregory Machin wrote: >>>> Hi. >>>> At the moment it seems my machines just update to the latest current >>>> release . I install a 6.0 machine and run yum update , and next thing >>>> its 6.2 . >>>> >>>> I have a requirement where I need machines to only upgrade to even >>>> numbered sub releases eg: 6.0 , 6.2, 6.4 and only on my approval. But >>>> will allow updates within a given release. >>> There is no provided functionality to do this, that is, CentOS doesn't >>> differentiate between what you call updates and upgrades. >> I want to point out that neither does Red Hat. >> >> If you are on the RHEL 6 channel and if you run an update after you >> install RHEL 6.0, you will be at RHEL 6.2. >> >> 6.0, 6.1, and 6.2 are really only point in time freezes of installation >> media. They are not separate entities or versions. > To be fair that's not entierly true. At those points in time updates are more > numerous and higher impact (new kernel -131 -> -220 last time, driver updates, > some new tech. etc.). Sure, and people can and should test things before deployment. But what I said is true ... there is no real mechanism to do this in Red Hat either, other than to buy a RHN satellite server (or create your own RHEL yum repos) and populate those separately with tested RPMS yourself. If you run updates when subscribed to RHN, it works just like running updates in CentOS ... you get all or nothing unless you take actions manually to prevent it. There are several solutions to be able to make that happen ... manual repos yourself, mrepo, spacewalk, etc. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 262 bytes Desc: OpenPGP digital signature URL: <http://lists.centos.org/pipermail/centos/attachments/20120510/6114042a/attachment-0003.sig>