On Wed, 2006-09-06 at 21:42 +0200, Joakim Sernbrant wrote:
Why was the update to 4.4 automatic? Having a lot of new features automatically installed it not why we run an "enterprise" OS. I would like to be able to plan and test that kind of events.
A better way of handling it would be what I am used with from another "enterprise" distro:
By all means ... before you update a mission critical system you should do testing and planning.
Already yum looks for the release in the "Version:" header of the package specified in yum.conf:distroverpkg (centos-release in our case). However the version is 4 and not 4.4 as one would expect (and 4 in the 4.3 version as well).
That is exactly as designed...
---------------------------------------
Ummm ... our update procedures are exactly like upstream
CentOS-4 is the version ... 4.3 and 4.4 are update sets of CentOS-4. If you do updates, you get updates. If you don't want updates, then don't update.
If you had RHEL-4 (update 3) installed the day before they released RHEL-4 update 4 ... and if you ran the command:
up2date -u
on the day after they released RHEL-4 update 4 ... then you would have gotten the exact same package updates. (Except we use yum for updates and not RHN)
# rpm -qp --queryformat="%{version}\n" centos-release-4-3.2.src.rpm 4 # rpm -qp --queryformat="%{version}\n" centos-release-4-4.2.i386.rpm 4
This means that $releasever in our CentOS-Base.repo will be 4 and not 4.4 as we would like.
If the the "Version:" of the centos-release rpm is in sync with the CentOS release version all you have to do to switch is:
rpm -U "new centos-release rpm" yum update yum yum update
Simple and predictable.
Except, we don't maintain the 4.1, 4.2, 4.3, 4.4 trees indefinitely, we maintain a 4 tree ... that is always updated to be just like running up2date upstream.
You are confusing moving from CentOS-2 to CentOS-3 to CentOS-4 with moving from CentOS-4.1 to CentOS-4.2 to CentOS-4.3. They are not the same.