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:
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).
# 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.
/// joakim
On Wed, Sep 06, 2006 at 09:42:09PM +0200, Joakim Sernbrant enlightened us:
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.
Because CentOS 4 is CentOS 4. The point releases are just milestones during which more than just security fixes are released. This is identical to how upstream releases.
If you don't want surprises, I suggest you don't turn yum on to auto update and point it at mirrors you don't control.
A better way of handling it would be what I am used with from another "enterprise" distro:
The best way of handling it is for you to have your own repository into which you put updates you have tested in your sandbox/testbed.
QED
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.
you should read up on what a point release actually is.
Joakim Sernbrant wrote:
you should read up on what a point release actually is.
Fair enough. I was used to scientific linux where you had to opt-in for a new point release and was a bit surprised. Just assumed the upstream vendor did it the same way.
they ( = upstream ) are working on some way to achieve this... not having to roll out any package updates, and splitting each point release into a 18 month cycle.
Details on this when they are available.... we might see this kick off in 4.5.x timezone.
On Wed, 2006-09-06 at 21:14 +0100, Karanbir Singh wrote:
Joakim Sernbrant wrote:
you should read up on what a point release actually is.
Fair enough. I was used to scientific linux where you had to opt-in for a new point release and was a bit surprised. Just assumed the upstream vendor did it the same way.
they ( = upstream ) are working on some way to achieve this... not having to roll out any package updates, and splitting each point release into a 18 month cycle.
Details on this when they are available.... we might see this kick off in 4.5.x timezone.
And of course if / when they do that ... we will figure out a way to also mirror that process :)
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.
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.
Until RH releases 4.5.0,4.5.1,etc with plans to update in similar fashion to what scientific linux has done. That should quite thoroughly confuse the hell out of everyone.
-
Jim Perrin -
Joakim Sernbrant -
Johnny Hughes -
Karanbir Singh -
Matt Hyclak