Apache OpenOffice (AOO) Bugzilla – Issue 97054
Fedora/Redhat: Conflicting packages for openoffice.org-ure
Last modified: 2009-07-12 19:11:21 UTC
When installing OpenOffice.org 3 (or StarOffice 9) on Fedora/Redhat Linux, the next "yum -y upgrade" replaces the openoffice.org-ure package with an older one thereby also changing the location of libuno_sal.3. The office does not start anymore. This is - to my understanding - only partly a problem on our side. However, the vanilla OpenOffice/StarOffice builds should probably use another naming scheme. @SB: Can you please have a look? If you need to reproduce, please do the following: * Install fresh Fedora 9 or 10 * Remove any OpenOffice.org related files (yum remove openoffice.org* ooobasis*) * Install either StarOffice 9 or OpenOffice.org 3 * Run yum upgrade -> The list of packages to be replaced contains openoffice.org-ure
@SB: Please evaluate the effort, i am considering making this a blocker for 3.0.1.
@cmc: I always thought distros (esp. if they changed things relative to vanilla, like installation paths) wanted to chose different package names than vanilla. Can you shed light on what the situation for Fedora is?
@sb: We just discussed this within QA. Fedora does not rename the packages properly. We cannot fix this without breaking *our* upgrade process (as OF correctly noted) so there is nothing we could/should do. There is a slightly inconvenient workaround available, which is to edit /etc/yum.conf to contain the line exclude=openoffice.org-ure which then causes the update process to ignore the URE package provided by Fedora. I'm closing the issue as wontfix.
Regardless of the status of this issue, it would of course be good if the problem was eventually solved on the Fedora side (i.e., at a time when Fedora can change the name of its ure rpm, whenever that may be).
The Fedora rpms have to be called something and they can't install into /opt. We take the natural names of openoffice.org-writer, openoffice.org-calc, openoffice.org-ure etc. A couple of rpms names will collide with vanilla ones and we don't make up convoluted names to avoid the situation. FWIW this has been unchanged for years in that installing the "vanilla" OOo and not filtering out openoffice.org-* from yum via excludes will replace it with the fedora rpms if the rpm numbers happen to be higher. The same thing will generally happen with a lot of other rpms if they are installed from some third-party location and it so happens that packages with the same names are also available in the fedora repository. If you wanted a quick-and-dirty fix you could bung in an epoch of e.g. 2: or something into the vanilla rpms which would make them always higher than the fedora OOo epoch of 1: regardless of the rest of the version string of the rpms.
@SB: Would cmc's suggestion be an option?
@is: Can you give an answer to jsk's <#desc7> question?
FWIW if there are duplicate files in two rpms at the *same* location then the rpms would conflict, e.g. if there was /usr/share/applications/openoffice.org.desktop" in both packages for GNOME menus desktop integration. I don't think this happens at the moment, but just by luck because we have kept the names of our .desktop files the same as the first 2.0 snapshots ones we ever packaged
*** Issue 99966 has been marked as a duplicate of this issue. ***
*** Issue 102851 has been marked as a duplicate of this issue. ***
wontfix -> closed