Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 823217

Summary:	LibreOffice in 6.3 update and Epoch
Product:	Red Hat Enterprise Linux 6	Reporter:	Nelson Marques <nmo.marques>
Component:	libreoffice	Assignee:	Caolan McNamara <caolanm>
Status:	CLOSED UPSTREAM	QA Contact:	Desktop QE <desktop-qa-list>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	6.3	CC:	mstahl, tpelka
Target Milestone:	rc
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-05-20 07:45:45 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Nelson Marques 2012-05-20 00:09:54 UTC

I've updated my system to 6.3 Beta and noticed that openoffice.org was replaced by libreoffice. 

It's really great to see such an improvement. I do believe Apache OpenOffice offers probably a better answer for my needs. I've installed the upstream binaries (from a local repo), unfortunatly something happens:

 1) new openoffice.org-ure from redhat has Epoch set to 1; this takes YUM to update the RPM provided by Apache OpenOffice, thus breaking the software.

 2) users can dodge this by add openoffice.org-ure to exclusion in yum.conf; but is it really necessary to go that far?
 
 3) yum might also update some language related RPMs.

Is there anyway this can be mitigated for users? Or is exclusion of packages in YUM something ok to do?



Steps to Reproduce:
1. Update to 6.3 beta;
2. Install a local repo with the RPMs from Apache OpenOffice;
3. Uninstall LibreOffice
4. Install Apache OpenOffice from local repo;
5. Do a yum update... (Apache OpenOffice RPMs are updated by Libre Office ones due to Epoch (?)).
  
Actual results:
Update happens blowing up other vendors stuff


Expected results:
Update should happen without blowing up other vendors stuff

Comment 1 Caolan McNamara 2012-05-20 07:45:45 UTC

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

Comment 2 Michael Stahl 2012-05-20 15:08:42 UTC

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?]

Comment 3 Nelson Marques 2012-05-20 19:56:10 UTC

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.