Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 154640 - OpenOffice.org rpms provide wrong libraries to dependency tree
Summary: OpenOffice.org rpms provide wrong libraries to dependency tree
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: openoffice.org
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Caolan McNamara
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-04-13 09:38 UTC by Mephisto
Modified: 2007-11-30 22:11 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-04-13 10:04:18 UTC


Attachments (Terms of Use)

Description Mephisto 2005-04-13 09:38:29 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050328 Firefox/1.0.2 Fedora/1.0.2-3

Description of problem:
This has been around for some time, but since its still not fixed, i'll just post it as bug, in case you're not aware of this.
The openoffice.org rpm's supply a lot of fake provided libraries, which causes other packages to think that all their dependencies are satisfied, while they are not, because those libraries are not available to them.
My personal example is the Mono framework from freshrpms, which needs libicu 2.6, and the current version of libicu is 3.2, which is not compatible, so the mono rpms install fine, but dont work because they lack libraries.

The openoffice rpm's should not claim to provide packages that they do not.

Version-Release number of selected component (if applicable):
openoffice.org-*-1.9.92-1

How reproducible:
Always

Steps to Reproduce:
1. install openoffice.org
2. install something that needs one of the libraries falsely provided by OOo (like e.g. the mono framework from freshrpms)
3.
  

Actual Results:  the package installed fine, but doesnt work.

Expected Results:  the rpm system should've mentioned the dependency problems.

Additional info:

i personally would even prefer OOo to use the system libs instead, so both the download size and consumed disk space would get lower, but i dont know if this possible, so just ignore this comment if its not.

Comment 1 Caolan McNamara 2005-04-13 10:04:18 UTC
OOo uses system libs whereever possible. mozilla-nss, jpeg, zlib etc etc. There
are a few outstanding issues, gcj and db4 don't work so we have to still have
the OOo db3 copy, upstream OOo has patched libxmlsec and icu so we have to have
their patched copies. I'm trying to get progress on libxmlsec patches, but the
icu one is unchanged since 1.1.X and it's a pain but the OOo copy is quite
heavily patched and necessary for OOo to function.

I "can't fix" icu in the short to medium term, though I'm always trying to
reduce the copies of libraries.


Note You need to log in before you can comment on or make changes to this bug.