Red Hat Bugzilla – Bug 505783
Please rename OpenChange libmapi.so to avoid conflicts with Zarafa libmapi.so
Last modified: 2009-06-30 13:44:17 EDT
Description of problem:
We've the unfortunate situation, that OpenChange and Zarafa are providing a
libmapi.so library with different functionality, but same naming. According
to fedora-packaging, both libraries should get renamed to not conflict each
Please read the following e-mails for your information:
In addition to my investigation to find information about libmapi.so, I got
told, that OpenChange libmapi.so only has 30% of the feature set of Zarafa
libmapi.so and currently OpenChange libmapi.so is not in productive usage at
hundreds of companies and organisations out there as Zarafa is already.
Thank you for your cooperation.
Version-Release number of selected component (if applicable):
Conflict between OpenChange libmapi.so and Zarafa libmapi.so.
No conflict due to renamed libmapi.so libraries.
Are you sure it's just libmapi.so that's in conflict?
OpenChange also installs:
Would it be sufficient to just move the libraries?
Then just the pkg-config files would need modified/renamed.
The only overlap is from my point of view only libmapi.so, not more:
/usr/lib/libmapi.so -> libmapi.so.0.0.0
/usr/lib/libmapi.so.0 -> libmapi.so.0.0.0
There are some libraries such as libicalmapi.so* or libinetmapi.so*, but I
can't see there overlaps. The only pkg-config file is zarafa.pc which focuses
to Zarafa but not especially to Zarafa libmapi.
Fixed in openchange-0.8.2-3.fc12.
- Renamed /usr/lib/libmapi.so* to /usr/lib/libmapi-openchange.so*.
- Modified the pkg-config metadata to use the new library name.
- Rebuilt evolution-mapi against it.
I don't see why it wouldn't be Zarafa's job to rename the library, especially as it's internal to Zarafa and not used anywhere else.
First, Matthew, thank you very much for your work! :)
As agreed with Toshio, both libraries will get renamed. And the library
from Zarafa is not only internal, it also can be used external, but as
of the moment, the package is a) not-yet in Fedora and b) no extensions
or similar stuff that could/would depend is packaged etc. because of a).
I'll speak with the OpenChange project and see if they'd be willing to install to a subdirectory -- e.g. $(libdir)/openchange -- so we don't have to permanently deviate from upstream.