On Tue, Dec 11, 2007 at 02:13:10PM -0800, MHR enlightened us:

...

--- MHR mhullrich@gmail.com wrote:

...

Now that I have upgraded to 5.1, yum wants to update my OOo from 2.3 BACK to 2.0.

Is it possible to get yum to recognize that 2.3 is newer than 2.0, or

should

...

...

I just exclude OOo from the updates?

I'm thinking its operator error. :-D

Well, let's assume that you are right (and remember how one spells assume) and see:

# rpm -qa | grep -i openoffice openoffice.org-core03u-2.3.0-9221 openoffice.org-core07-2.3.0-9221 openoffice.org-onlineupdate-2.3.0-9221 openoffice.org-writer-2.3.0-9221 openoffice.org-core04-2.3.0-9221 openoffice.org-core10-2.3.0-9221 openoffice.org-mandriva-menus-2.3-9215 openoffice.org-draw-2.3.0-9221 openoffice.org-core03-2.3.0-9221 openoffice.org-core09-2.3.0-9221 openoffice.org-suse-menus-2.3-9215 openoffice.org-headless-2.3.0-9221 openoffice.org-pyuno-2.3.0-9221 openoffice.org-core05u-2.3.0-9221 openoffice.org-redhat-menus-2.3-9215 openoffice.org-core-2.0.4-5.4.24 openoffice.org-calc-2.3.0-9221 openoffice.org-graphicfilter-2.3.0-9221 openoffice.org-core04u-2.3.0-9221 openoffice.org-freedesktop-menus-2.3-9215 openoffice.org-gnome-integration-2.3.0-9221 openoffice.org-math-2.3.0-9221 openoffice.org-core01-2.3.0-9221 openoffice.org-core06-2.3.0-9221 openoffice.org-emailmerge-2.3.0-9221 openoffice.org-core05-2.3.0-9221 openoffice.org-impress-2.3.0-9221 openoffice.org-core08-2.3.0-9221 openoffice.org-kde-integration-2.3.0-9221 openoffice.org-base-2.3.0-9221 openoffice.org-core02-2.3.0-9221 openoffice.org-xsltfilter-2.3.0-9221

# yum update Loading "installonlyn" plugin Setting up Update Process Setting up repositories kbs-CentOS-Extras 100% |=========================| 951 B 00:00

base 100% |=========================| 1.1 kB 00:00

updates 100% |=========================| 951 B 00:00

http://wuarchive.wustl.edu/pub/linux/distributions/centos/5.1/addons/x86_64/...: [Errno 14] HTTP Error 500: Internal Server Error Trying other mirror. addons 100% |=========================| 951 B 00:00

extras 100% |=========================| 1.1 kB 00:00

Reading repository metadata in from local files Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package openoffice.org-calc.x86_64 1:2.0.4-5.4.24 set to be updated ---> Package openoffice.org-emailmerge.x86_64 1:2.0.4-5.4.24 set to be updated ---> Package openoffice.org-base.x86_64 1:2.0.4-5.4.24 set to be updated ---> Package openoffice.org-graphicfilter.x86_64 1:2.0.4-5.4.24 set to be updated ---> Package openoffice.org-math.x86_64 1:2.0.4-5.4.24 set to be updated ---> Package openoffice.org-xsltfilter.x86_64 1:2.0.4-5.4.24 set to be updated ---> Package openoffice.org-impress.x86_64 1:2.0.4-5.4.24 set to be updated ---> Package openoffice.org-draw.x86_64 1:2.0.4-5.4.24 set to be updated ---> Package openoffice.org-pyuno.x86_64 1:2.0.4-5.4.24 set to be updated ---> Package openoffice.org-writer.x86_64 1:2.0.4-5.4.24 set to be updated --> Running transaction check

Dependencies Resolved

============================================================================= Package Arch Version Repository Size ============================================================================= Updating: openoffice.org-base x86_64 1:2.0.4-5.4.24 base 865 k openoffice.org-calc x86_64 1:2.0.4-5.4.24 base 8.1 M openoffice.org-draw x86_64 1:2.0.4-5.4.24 base 1.1 M openoffice.org-emailmerge x86_64 1:2.0.4-5.4.24 base 63 k openoffice.org-graphicfilter x86_64 1:2.0.4-5.4.24 base 209 k openoffice.org-impress x86_64 1:2.0.4-5.4.24 base 1.6 M openoffice.org-math x86_64 1:2.0.4-5.4.24 base 1.4 M openoffice.org-pyuno x86_64 1:2.0.4-5.4.24 base 190 k openoffice.org-writer x86_64 1:2.0.4-5.4.24 base 3.1 M openoffice.org-xsltfilter x86_64 1:2.0.4-5.4.24 base 97 k

Transaction Summary

Install 0 Package(s) Update 10 Package(s) Remove 0 Package(s)

Total download size: 17 M Is this ok [y/N]:

Please note: the version number listed in the rpm -qa is 2.3.0, but the version number listed in the yum update confirmation is 2.0.4.

I haven't even touched my yum repos.d directories since I added rpmforge back in April.

So, if this is operator error, please enlighten me as to where so I can operate better.

If by some staggering coincidence it is not operator error, please refrain from making that instant assumption henceforth, mai oui? Merci beaucoup.

mhr

rpm -qa --queryformat "%{epoch}:%{name}-%{release}-%{version}.%{arch}" openoffice*

I bet they have an epoch of 0, but the 2.0.4 packages have an epoch of 1, which means they are newer, even though the version number is smaller.

Matt

On Tue, Dec 11, 2007 at 07:45:36PM -0800, MHR enlightened us:

...

On Tue, Dec 11, 2007 at 02:13:10PM -0800, MHR enlightened us:

...

Please note: the version number listed in the rpm -qa is 2.3.0, but the version number listed in the yum update confirmation is 2.0.4.

rpm -qa --queryformat "%{epoch}:%{name}-%{release}-%{version}.%{arch}"

openoffice*

...

I bet they have an epoch of 0, but the 2.0.4 packages have an epoch of 1, which means they are newer, even though the version number is smaller.

They work like the 2.0 version from before, meaning the same bug I moved to 2.3 to avoid.

So, I guess I'll put in an exclude until something else changes.

I wasn't terribly clear. By "newer", I only mean in the eyes of RPM. You could take foo-0.0.0.0.1beta, give it an epoch of 1 and foo-99.9pro with the default epoch of 0, and RPM would think the 0.0.0.0.1beta was newer.

I'm not sure why the openoffice 2.x RPMs have an epoch of 1.

Matt

Mhr wrote on Thu, 13 Dec 2007 16:45:34 -0800:

If that's true, doesn't it break some kind of unwritten rule to supersede newer software from an OEM source with older software that has been rebuilt?

I'm just "reading by" but if I understood you correctly you installed a 32bit rpm of the 2.3 version (which you missed to tell from the beginning) and now yum wants to "update" to a 2.0.4 64bit rpm version. I think you missed a vital point - there's no connection between the 32bit and 64bit packages, it will never attempt to "update" a 32bit package to 64bit. What actually happens is that it updates the installed older 64bit package to the newer one. It doesn't matter at all if you have a 32bit version installed or not. It's just a mystery why those packages are not shown in your rpm -qa run. But it's clear that yum thinks they are installed.

Kai

On Thu, Dec 13, 2007 at 07:07:12PM -0800, MHR alleged:

On Dec 13, 2007 6:31 PM, Kai Schaetzl maillists@conactive.com wrote:

...

Mhr wrote on Thu, 13 Dec 2007 16:45:34 -0800:

...

If that's true, doesn't it break some kind of unwritten rule to

supersede newer software from an OEM source with older software that has been rebuilt?

...

I'm just "reading by" but if I understood you correctly you installed a 32bit rpm of the 2.3 version (which you missed to tell from the beginning) and now yum wants to "update" to a 2.0.4 64bit rpm version. I think you missed a vital point - there's no connection between the 32bit and 64bit packages, it will never attempt to "update" a 32bit package to 64bit. What actually happens is that it updates the installed older 64bit package to the newer one. It doesn't matter at all if you have a 32bit version installed or not. It's just a mystery why those packages are not shown in your rpm -qa run. But it's clear that yum thinks they are installed.

Interesting points, but not the one I was aiming at.

My point was that the 2.3.1 version from OOo is newer than the 2.0.4 version from CentOS (although there is an epoch difference which makes the CentOS version look newer), and it is modified from the original 2.0.4 OOo distribution in that the one that comes with CentOS is a 64-bit package.

IOW, the CentOS distribution is modified from the original that came from OOo, but it is still an older revision than the newest one from OOo.

Shouldn't it be the case that a newer revision is NOT updated with an older one, epochs notwithstanding (is the epoch an OOo thing or a CentOS thing?) when the old revision's newer release is still a rebuild of an older revision?

(Is this getting too convoluted? I wouldn't think so, but....)

What do you CentOS folks think?

Epoch is an rpm thing. It is used to force upgrades. It is generally discouraged because, as you are seeing, it causes a lot of confusion.

You may notice that many packages in the distro have an epoch. Each one was added for a specific need, and is now stuck forever: $ rpm -qa --qf '%{NAME}-%{EPOCH}:%{VERSION}-%{RELEASE}.%{ARCH}\n' | grep -v '(none)'

The CentOS package (or rather, the Upstream Linux Vendor's package) has an epoch of 1. At some point in the past, there was a very good reason why someone added it.

At this point, the solution is to just exclude it from the CentOS repos in your yum config.