Private-libraries in /usr/lib* - invalid soname.

Alec Leamas leamas.alec at gmail.com
Sat Apr 21 03:50:37 UTC 2012


On 04/20/2012 06:16 PM, Toshio Kuratomi wrote:
> On Fri, Apr 20, 2012 at 05:59:44PM +0200, Kevin Kofler wrote:
>> Toshio Kuratomi wrote:
>>> * Private unversiond libs in %{_libdir}.  -- I would consider this a
>>> blocker unless shown that they have to be there (and I would patch the
>>> build scripts to fix this if necessary).
>> Why is this a problem, assuming the name doesn't conflict with anything? (Of
>> course a generic name like libparser.so would be a problem.)
>>
> * Organizationally -- I wouldn't want it there because it serves a wholly
>    different purpose.
> * Naming-conflict wise, it's easier to tell people on review to move private
>    libs on review than to find out later that there's a conlict and then have
>    to get two maintainres to decide whether some of their libs are private,
>    who is responsible for moving their libraries, etc.
> * For rpm, it adds unnecessary provides which are not only potential
>    conflicts but also add bloat to the repodata that users have to download.
>
> I suppose in strict answer to your question; not every reviewer would need
> consider this a blocker.  But if I was reviewing a package, I would
> submit patches to make it use a private directory and expect that those
> patches would be applied for approval and its one of the things Id see if
> I was evaluating a reviewer and say, eh... I can see why you don't require
> that but it does make me feel you're a little more sloppy than otherwise.
>
> -Toshio
>
Hm... trying to summarize and expand to a more complete draft on how to 
handle 'invalid-soname' warning:
----

If the warning is about a public library, upstream should be informed, 
preferably with a patch. Don't apply patch until it's merged with 
upstream for compatibility reasons. The unversioned so-file goes to a 
binary package. (Are there situations when applying a patch is 
preferable even when upstream don't?)

If the warning is about a private library stored outside the linker 
paths, it can be ignored.

If the warning is about a private library in the linker paths  we should 
try hard to patch the package to move it outside the paths using e. g.,  
a private dir under /usr/libx* and a rpath. Patches goes upstream.

If above is not possible and package needs to store a private library in 
the linkers paths  the library must have a name unlikely to clash with 
others. In this situation, the package  should be filtered to avoid 
providing the private lib to other packages.
---

The last one, about filtering, is my own. For me, it seems like a 
logical conclusion (?)

Thoughts? Should something like this go into "Common Rpmlint Issues" ?

--alec


More information about the devel mailing list