Bug 857175
Summary: | Error: Package: openoffice.org3-3.4.0-9590.i586 (@/openoffice.org3-3.4.0-9590.i586) when running yum update. GUI version gets stuck as "in queue". | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | JW Hall <crashhal> |
Component: | libreoffice | Assignee: | Caolan McNamara <caolanm> |
Status: | CLOSED UPSTREAM | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | unspecified | ||
Version: | 17 | CC: | ancient_now, caolanm, crashhal, dtardon, erack, extras-orphan, ltinkl, mstahl, notting, sbergman |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i686 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2012-09-13 19:48:32 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
JW Hall
2012-09-13 18:05:04 UTC
libreoffice, openoffice openoffice.org3-3.4.0-9590.i586 etc, are third party rpms, i.e. presumably direct from Apache OpenOffice. Historically there was the unfortunate problem that both a fedora openoffice.org-ure rpm and Sun OpenOffice.org openoffice.org-ure rpm existed with the fedora one of a 1 epoch and the Sun OpenOffice.org one of no epoch, i.e. the fedora ure was always "newer" regardless of the rest of the version number. So, if for some reason someone wanted to use the Sun OpenOffice.org binary build rpms instead of the Fedora one, then a yum update would always remove the Sun OpenOffice.org ure and attempt to replace it with the Fedora one. One needed to fiddle with the yum.conf to exclude openoffice.org-ure from the upgrade process. Now that we're using libreoffice I had to insert obsoletes and provides for our previous fedora openoffice.org builds in order for our own upgrade path to work. So the problem persists in this new guise. The only way the problem will "go away" is that a) Apache OpenOffice bumps their Epoch to 2 or higher b) Determine if http://fedoraproject.org/wiki/Packaging:Guidelines "If there is no standard naming for a package or other long term naming compatibility requirements involved with the rename, the Provides should be assumed to be deprecated and short lived and removed in the distro release after the next one (ie. if introduced in FC-X, keep in all subsequent package revisions for distros FC-X and FC-(X+1), drop in FC-(X+2))" applies and drop the provides/requires for our next release. I'm not completely certain that it does apply however and prefer a workaround is to either remove the apache openoffice rpms (something like rpm --erase `rpm -qf /opt/OpenOffice*|xargs` would likely work) and use the fedora-provided libreoffice rpms or to add the right excludes lines to yum.conf to make yum not pull in the libreoffice rpms I was going to use libre office, but it wouldn't install using add/remove software. I went to openoffice.org and got it to install. I still forget, sometimes, that using yum from terminal will many times tell me why it didn't get installed. I will uninstall ooo and try installing libre in terminal. (In reply to comment #2) > b) Determine if http://fedoraproject.org/wiki/Packaging:Guidelines "If there > is no standard naming for a package or other long term naming compatibility > requirements involved with the rename, the Provides should be assumed to be > deprecated and short lived and removed in the distro release after the next > one (ie. if introduced in FC-X, keep in all subsequent package revisions for > distros FC-X and FC-(X+1), drop in FC-(X+2))" applies and drop the > provides/requires for our next release. > does apply however and prefer a I think it does apply, for the following reasons: 1. "openoffice.org" can hardly be considered a "standard name" for the package, because it has never been used consistently across distributions 2. There are not long-term compatibility issues. Given the nature of the package, these would necesarrily only involve -ure and -sdk. But we did broke the only thing that could have assured seamless migration (from build's POV) of packages depending on openoffice.org to libreoffice--the location of the setsdkenv script--so these packages had to be updated anyway. |