Hi,
With the release of 5.2 "yum update" seems to be upgrading our computers from CentOS 5.1 to CentOS 5.2. I note from release notes for 5.2 that you are only supposed to get 5.2 if you type in "yum upgrade". On two seperate machines entering "yum update" has resulted in yum geting repo information for packages with versions that only exist in the base repository of centos 5.2.
The following snippet shows the beginning of yum update on a x86_64 server. It has noticed python-2.4.3-21.el5.x86_64, ltrace-0.5-7.45svn.el5.x86_64 and system-config-securitylevel-tui.x86_64 0:1.6.29.1-2.1.el5 which are a CentOs 5.2 package. On a workstation yum update resulted in upgrade of firefox from 1.5 to 3.0-0 beta5.
Can I stop this from happening? Ideally I would like to stay on a particulare version of CentOS eg 5.2 until we can do a controlled upgrade. Maybe we have the same problem as having stable specified in a debian sources.list where what is meant by stable changes when a new version of debian is released.
[root@huxley-ci yum.repos.d]# yum update Loading "installonlyn" plugin Loading "dellsysidplugin" plugin Setting up Update Process Setting up repositories epel 100% |=========================| 1.1 kB 00:00 dell-hardware-auto 100% |=========================| 951 B 00:00 extras 100% |=========================| 1.1 kB 00:00 updates 100% |=========================| 951 B 00:00 base 100% |=========================| 1.1 kB 00:00 addons 100% |=========================| 951 B 00:00 dell-hardware-main 100% |=========================| 951 B 00:00 Reading repository metadata in from local files primary.xml.gz 100% |=========================| 1.0 MB 00:05 ################################################## 3431/3431 primary.xml.gz 100% |=========================| 86 kB 00:00 ################################################## 235/235 primary.xml.gz 100% |=========================| 88 kB 00:01 ################################################## 183/183 Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for nspr to pack into transaction set. nspr-4.7.0.99.2-1.el5.x86 100% |=========================| 5.5 kB 00:00 ---> Package nspr.x86_64 0:4.7.0.99.2-1.el5 set to be updated ---> Downloading header for python to pack into transaction set. python-2.4.3-21.el5.x86_6 100% |=========================| 225 kB 00:01 ---> Package python.x86_64 0:2.4.3-21.el5 set to be updated ---> Downloading header for pam to pack into transaction set. pam-0.99.6.2-3.27.el5.i38 100% |=========================| 84 kB 00:00 ---> Package pam.i386 0:0.99.6.2-3.27.el5 set to be updated ---> Downloading header for ltrace to pack into transaction set. ltrace-0.5-7.45svn.el5.x8 100% |=========================| 8.1 kB 00:00 ---> Package ltrace.x86_64 0:0.5-7.45svn.el5 set to be updated ---> Downloading header for system-config-securitylevel-tui to pack into transaction set. system-config-securitylev 100% |=========================| 29 kB 00:00 ---> Package system-config-securitylevel-tui.x86_64 0:1.6.29.1-2.1.el5 set to be updated
Ben Marsh wrote:
Hi,
With the release of 5.2 "yum update" seems to be upgrading our computers from CentOS 5.1 to CentOS 5.2. I note from release notes for 5.2 that you are only supposed to get 5.2 if you type in "yum upgrade". On two seperate machines entering "yum update" has resulted in yum geting repo information for packages with versions that only exist in the base repository of centos 5.2.
<snipped>
yum update will update your machine to the most current packages just like yum upgrade unless you've modified your /etc/yum.conf to remove obsoletes=1.
Per the man page yum update with obsoletes enabled is the same as yum upgrade. I believe that if you want to remain at 5.1 you'll have to stop updating. It is expected that running yum update will bring you forward to 5.2.
Can I stop this from happening? Ideally I would like to stay on a particulare version of CentOS eg 5.2 until we can do a controlled upgrade. Maybe we have the same problem as having stable specified in a debian sources.list where what is meant by stable changes when a new version of debian is released.
<snipped yum output> You're going to be missing security updates. This has been discussed here before. The minor number could be compared to a service pack from the Windows world. Depending on one's environment, one may not want to necessarily throw the latest service packs into production right away either.
HTH
Alex White
Ben Marsh wrote:
Hi,
With the release of 5.2 "yum update" seems to be upgrading our computers from CentOS 5.1 to CentOS 5.2. I note from release notes for 5.2 that you are only supposed to get 5.2 if you type in "yum upgrade". On two seperate machines entering "yum update" has resulted in yum geting repo information for packages with versions that only exist in the base repository of centos 5.2.
The following snippet shows the beginning of yum update on a x86_64 server. It has noticed python-2.4.3-21.el5.x86_64, ltrace-0.5-7.45svn.el5.x86_64 and system-config-securitylevel-tui.x86_64 0:1.6.29.1-2.1.el5 which are a CentOs 5.2 package. On a workstation yum update resulted in upgrade of firefox from 1.5 to 3.0-0 beta5.
Can I stop this from happening? Ideally I would like to stay on a particulare version of CentOS eg 5.2 until we can do a controlled upgrade. Maybe we have the same problem as having stable specified in a debian sources.list where what is meant by stable changes when a new version of debian is released.
If you desire version control, the you need to setup your own mirrors and only put authorized configuration in those mirrors. Then you run updates against your mirrors only.
CentOS-5 is the real version ... 5.2 is just a point in time set of updates for CentOS-5. Understand that if you had RHEL-5 and ran an update, it would also update you to the same packages. What this means is that 5.2 is just an update set for CentOS-5 .. not really a new version.
Johnny Hughes wrote:
CentOS-5 is the real version ... 5.2 is just a point in time set of updates for CentOS-5. Understand that if you had RHEL-5 and ran an update, it would also update you to the same packages. What this means is that 5.2 is just an update set for CentOS-5 .. not really a new version.
I think the firefox/OOo version jumps are the surprises here. We've come to expect boring consistency with few feature changes across minor updates. I think it is a great thing for the desktop apps to change faster than the base os and server apps, but it seems like an upstream policy change especially for the big jump in firefox.
Les Mikesell wrote:
Johnny Hughes wrote:
CentOS-5 is the real version ... 5.2 is just a point in time set of updates for CentOS-5. Understand that if you had RHEL-5 and ran an update, it would also update you to the same packages. What this means is that 5.2 is just an update set for CentOS-5 .. not really a new version.
I think the firefox/OOo version jumps are the surprises here. We've come to expect boring consistency with few feature changes across minor updates. I think it is a great thing for the desktop apps to change faster than the base os and server apps, but it seems like an upstream policy change especially for the big jump in firefox.
That may be ... but it is not a policy we (the CentOS Project) made. Also, if you have a RHEL-5 subscription and you run an update, you get the same packages.
Also if one wants to not do all upgrades then one must devise their own method of version control ... for CentOS or for RHEL.
on 7-2-2008 10:37 AM Les Mikesell spake the following:
Johnny Hughes wrote:
CentOS-5 is the real version ... 5.2 is just a point in time set of updates for CentOS-5. Understand that if you had RHEL-5 and ran an update, it would also update you to the same packages. What this means is that 5.2 is just an update set for CentOS-5 .. not really a new version.
I think the firefox/OOo version jumps are the surprises here. We've come to expect boring consistency with few feature changes across minor updates. I think it is a great thing for the desktop apps to change faster than the base os and server apps, but it seems like an upstream policy change especially for the big jump in firefox.
I'm almost sure it was a logistics change and not policy. They probably hit a wall in backporting patches to 1.5 tree of Firefox. So if they had to jump, jump with both feet out!
Scott Silva wrote:
I'm almost sure it was a logistics change and not policy. They probably hit a wall in backporting patches to 1.5 tree of Firefox. So if they had to jump, jump with both feet out!
Just a personal preference but I liked how Debian approached it myself -
http://wiki.debian.org/Iceweasel
(specifically the part about back porting the fixes to the included version of Iceweasel rather than upgrading to a new major version)
It seems kind of scary that upstream would change major versions like that in a point release. They certainly have more resources to be able to back port stuff vs other distributions. Though I suppose since most of their installations are on servers it may not be such a big deal. All of my RHEL/CentOS systems are servers, none run any X11 apps, for that I use Debian or Ubuntu(for newer hardware) typically. My company's SSL VPN software for example doesn't work in Firefox 3. Though we are running an old version of the VPN software, our last update attempt resulted in the device losing it's configuration, haven't yet tried again. I can imagine the headache that would ensue in such an environment where things are controlled/tested, then a new major version gets installed automatically..ouch. Fortunately it's not something I have to deal with :)
nate
On Wed, 2008-07-02 at 12:37 -0500, Les Mikesell wrote:
I think the firefox/OOo version jumps are the surprises here. We've come to expect boring consistency with few feature changes across minor updates. I think it is a great thing for the desktop apps to change faster than the base os and server apps, but it seems like an upstream policy change especially for the big jump in firefox.
Unfortunately Firefox 1.x has become useless on too many sites. A reply from one was, essentially, gotta keep up with the Joneses.
Bob
-
Alex White -
Ben Marsh -
Bob Taylor -
Johnny Hughes -
Les Mikesell -
nate -
Scott Silva