Bug 121941 - openwbem has badly named shared libraries
Summary: openwbem has badly named shared libraries
Status: RESOLVED WONTFIX
Alias: None
Product: SUSE Linux 10.1
Classification: openSUSE
Component: Other (show other bugs)
Version: unspecified
Hardware: i586 All
: P5 - None : Enhancement (vote)
Target Milestone: ---
Assignee: Bart Whiteley
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-10-10 11:46 UTC by Martin Vidner
Modified: 2011-04-04 10:09 UTC (History)
1 user (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Martin Vidner 2005-10-10 11:46:57 UTC
When I run ldconfig on my machine with openwbem-3.1.0-4.1, it reports 
"/sbin/ldconfig: /usr/lib/libowprovider.so.4 is not a symbolic link" for many 
libraries. 
Also the newest openwbem-3.1.1-5 contains the libraries as libFOO.so.NUM. 
 
The proper way is to distribute libFOO.so.NUM.N2.N3 (usually .NUM.0.0) and 
have ldconfig create libFOO.so.NUM 
*-devel should contain libFOO.so, a symlink to libFOO.so.NUM 
Now I see that blocxx has the same problem.
Comment 1 Bodo Bauer 2006-04-24 11:38:39 UTC
There has been no activity for more than 3 month. I'm closing this bug as
WONTFIX. If you feel this is inappropriate and the bug should remain open,
or you have new information which may lead to an actual resolution, please
reopen the bug and add the new status.
Comment 2 Martin Vidner 2006-04-24 11:58:15 UTC
Using libtool (automatic with automake) helps with correct handling of libraries.
Comment 3 Bart Whiteley 2006-04-24 15:49:16 UTC
OpenWBEM used to use libtool.  We ditched it years ago and have been quite pleased with that decision.  In fact, other projects have also ditched libtool in favor of the approach used by OpenWBEM.  

OpenWBEM is used on a lot of platforms where libtool doesn't work very well at all with c++ (or at least libtool didn't work well at the time).  

In short, the OpenWBEM community would not be interested in returning to libtool. 
Comment 4 Martin Vidner 2006-04-24 16:12:21 UTC
I see, then I suggest asking on packagers@suse.de about an example of proper library packaging without it. I'm sure there's a package that can be used as an example.
Comment 5 Marius Tomaschewski 2006-04-25 15:07:45 UTC
AFAIK there is no reason for any additional ".0.0" - one number at
the end is sufficient. If this number changes, it means that the
lib is not binary compatibile to the previous one any more.

You can of course use the libtool numbering (like in limal) to allow
breaking of the binary compatibility at minor version level and to
specify binary compatible ranges encoded in the numbers.
But this is just a flexibility issue.

In blocxx all is fine. The current 1.0.0 version uses libblocxx.so.4
and if we break the binary compatibility in 1.0.1 version, it will be
increased to libblocxx.so.5 and the rpm package will provide both.
The libblocxx.so link is provided by the blocxx-devel package.


The only point are the links "libopenwbem.so -> libopenwbem.so.4"
provided in the "openwbem" package, instead of "openwbem-devel".

Some of them are required (because they are loaded dynamically),
but some can be moved into the "-devel" package.

Lowered severity to enhancement, since this IMO cosmetic only.
If I am wrong, please just revert my change and explain why.
Comment 6 Larry Finger 2011-04-04 01:56:32 UTC
The version with which you had the bug is now obsolete. I'll close this as NORESPONSE. If you can still reproduce it in current 11.4, please reopen the bug and move it to the appropriate version. Thanks!