Bug 156039 - Virtual Provides conflict with other packages in Core and Extras
Virtual Provides conflict with other packages in Core and Extras
Product: Fedora
Classification: Fedora
Component: openoffice.org (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Caolan McNamara
Depends On:
Blocks: FC4Blocker
  Show dependency treegraph
Reported: 2005-04-26 17:12 EDT by Michael Schwendt
Modified: 2007-11-30 17:11 EST (History)
3 users (show)

See Also:
Fixed In Version: 1.9.99-2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-05-04 04:34:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
spec patch idea (1.08 KB, patch)
2005-04-27 08:23 EDT, Michael Schwendt
no flags Details | Diff
find-provides filter patch (378 bytes, patch)
2005-04-27 08:24 EDT, Michael Schwendt
no flags Details | Diff

  None (edit)
Description Michael Schwendt 2005-04-26 17:12:31 EDT
It is really _really_ bad and dangerous that the openoffice.org-core package
contains many virtual provides for all the DSOs it includes in a private
directory /usr/lib/openoffice.org1.9.89/program/ which is outside dynamic
linker's search path.

For instance, it creates this new conflict with Fedora Extras, which causes
programs to fail, when package resolvers use openoffice.org-core as the provider
for libsndfile.so.1 instead of "libsndfile" from Fedora Extras:

# rpm -q --whatprovides libsndfile.so.1

A package like openoffice.org-core, which provides the libsndfile DSO in 
/usr/lib/openoffice.org1.9.89/program/libsndfile.so.1, should NOT "Provides:
libsndfile.so.1", neither generated automatically nor added manually. The path,
where those DSOs are located, is not in /etc/ld.so.conf*  The run-time linker
will not link libsndfile.so.1 from there. Effectively, the OO.o-core package
does NOT really provides the DSO with the libsndfile.so.1 SONAME, but just
pollutes the RPM database with it and breaks packages, which depend on the SONAME.

Please filter out such DSO virtual provides.

openoffice.org-core does not even require libsndfile.so.1 itself. Watch this:

# rpm -q --whatrequires libsndfile.so.1

# rpm -q openoffice.org-core


In Fedora Extras, we could work around this with explicit "Requires:
libsndfile", but this is a step backwards.
Comment 1 Warren Togami 2005-04-26 17:23:27 EDT
We cannot ship FC4 with this.
Comment 2 Caolan McNamara 2005-04-27 03:10:24 EDT
And pray tell what's the desired solution? OOo contains libsndfile, there was no
enthusism for adding libsndfile as a supported fc4 package so OOo continues to
use the internal copy. Similiarly a patched xmlsec1 is in OOo.

Maybe unmarking the exec bit of selected libs such as libsndfile and xmlsec1
during %install might hackaround this, hiding them from the auto requires
finding of rpmbuild
Comment 3 Warren Togami 2005-04-27 03:17:48 EDT
Ville will a similar filter requires script (with grep -v) used in perl packages
work here too?
Comment 4 Michael Schwendt 2005-04-27 06:18:11 EDT
There's a conflict with Fedora Core, too (and this is no full install):

$ rpm -q --whatprovides libxmlsec1.so.1 

$ rpm -q --whatrequires libxmlsec1.so.1 


A problem is that OOo requires a few of the sonames itself:

$ pwd
$ ls *.so* | xargs -t -n 1 rpm -q --whatrequires | grep -v ^no
[lists the OOo package a few times]
Comment 5 Michael Schwendt 2005-04-27 06:24:56 EDT
Re: comment 2

They are -x here already, but maybe the symlinks to them cause them to be found.
Comment 6 Michael Schwendt 2005-04-27 08:23:32 EDT
Created attachment 113711 [details]
spec patch idea
Comment 7 Michael Schwendt 2005-04-27 08:24:17 EDT
Created attachment 113712 [details]
find-provides filter patch
Comment 8 Warren Togami 2005-04-27 14:48:26 EDT
After this is built can you generate a rpmdiff report from the previous version
and post it here?
Comment 9 Caolan McNamara 2005-04-29 09:44:06 EDT
the valgrind.spec apparently has a good pattern for this

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