Bug 121941

Summary:	openwbem has badly named shared libraries
Product:	[openSUSE] SUSE Linux 10.1	Reporter:	Martin Vidner <mvidner>
Component:	Other	Assignee:	Bart Whiteley <bwhiteley>
Status:	RESOLVED WONTFIX	QA Contact:	E-mail List <qa-bugs>
Severity:	Enhancement
Priority:	P5 - None	CC:	mt
Version:	unspecified
Target Milestone:	---
Hardware:	i586
OS:	All
Whiteboard:
Found By:	Other	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

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!