It has always been the case (can't remember if it was because of a once off need to bump the Epoch to get a Fedora/RHEL OOo of lower X.Y.Z to upgrade a Fedora/RHE OOo of higher X.Y.Z due to some bustage or some other reason) that the Red Hat packaged OOo had an Epoch of 1:

Sometime in 2008 or earlier I split the redhat OOO package up into subpackages, and one of them I decided to call "ure". Soon after that upstream OOo also split their packages and we ended up with a situation that the same name of "openoffice.org-ure" got used by both. That's been the case for 4+ years https://issues.apache.org/ooo/show_bug.cgi?id=97054
And because of our epoch the Red Hat rpms were always "higher" than the vanilla ones, regardless of the respective release version

The redhat RHEL libreoffice rpms have "Obsoletes: openoffice.org-ure < 1:3.3.1" We *have* to have those in order to be able to upgrade earlier installed RH openoffice.org packages with libreoffice. No way around that. (In Fedora land I can drop them by F-18 http://fedoraproject.org/wiki/Packaging:Guidelines)

FWIW, the effect would have been the same had you installed e.g. Apache OOo 3.4 on RHEL-6 and there was an upgrade to "classic" openoffice.org to "1:3.3.1", the Apache OOo 3.4.1 would have been upgraded to 1:3.3.1

My 2008 suggestion of setting Epoch of the thirdparty rpms to 2: has a hackaround would still work. Otherwise, the passage of time will cause the problem to go away in Fedora and RHEL-7 in that the obsoletes can be dropped, but nothing can really be done for RHEL-6, except follow the yum.conf block approach

hi Nelson,

in addition to Caolan's explanation of the historic (or as we used
to say in the Sun OpenOffice.org Writer team, "hysterical") reasons
for the epoch, another thing to consider is why the Apache OpenOffice
(incubating) project releases its RPM packages with the old
openoffice.org names, which does not make much sense to me,
and i vaguely remember the ASF's naming policies requiring
an "Apache" in the name, but maybe my memory is failing here.

also, the binaries released by the LibreOffice fork of OpenOffice.org
had RPMs with distinct "libo" and "libreoffice" names since the first
version, so it should be considered by the Apache OpenOffice (incubating)
fork of OpenOffice.org to rename their RPMs to some distinctive
"apacheopenoffice" or "aoo" or similar names, which would also
prevent the problem described in this bug, and perhaps similar
problems on other distributions.

[off-topic, but the Apache OpenOffice 3.4 binaries i installed variously
 refer to the program as "Apache OpenOffice" (e.g. start center) and
 "OpenOffice.org" (e.g. in help menu and the text of the about dialog);
 perhaps something went wrong with the re-branding?]

Thanks for the detailed information about the package. I just weird that users need to get exposed to this sort of things between vendors.

Either way I've repackaged their (Apache OpenOffice) binary distribution to make this go away with different names... a lot of filters on post-stream and some tinkering with the dependencies.

The yum.conf is a cool solution for 1 or 2 machines, but not for cases where people might have hundreds or thousands through different geographical locations.

Thanks.