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

[Alec Leamas]

On 04/20/2012 05:09 PM, Toshio Kuratomi wrote:
> On Fri, Apr 20, 2012 at 04:32:59PM +0200, Alec Leamas wrote:
>> On 04/20/2012 04:08 PM, Kevin Kofler wrote:
>>>   As far
>>> as I know, invalid-soname does not match any requirement in our packaging
>>> guidelines.
>> To my understanding, this is not really clear. From [1] I find (
>> thanks to  tibbs):
>>
>>> As an additional complication, some software generates unversioned
>>> shared objects which are not intended to be used as system
>>> libraries. These files are usually plugins or modular functionality
>>> specific to an application, and are not located in the ld library
>>> paths or cache. This means that they are not located directly in
>>> /usr/lib or /usr/lib64, or in a directory listed as a library path
>>> in /etc/ld.so.conf (or an /etc/ld.so.conf.d/config file). Usually,
>>> these unversioned shared objects can be found in a dedicated
>>> subdirectory under /usr/lib or /usr/lib64 (e.g. /usr/lib/purple-2/
>>> is the plugin directory used for libpurple applications). In these
>>> cases, the unversioned shared objects do not need to be placed in a
>>> -devel package.
>> I read those lines as "unversioned libs should  be outside of ld.so's
>> paths" - placing them in a -devel package makes no sense. Also, my
>> initial discussion on #fedora-devel pointed in the same direction.
>>
> I would agree more with your initial interpretation.  The libraries you are
> dealing with are private to the app, correct?  If so, create a directory
> like %{_libdir}/APPLICATION and place the libraries into that directory
> makes sense.  If these are libraries (rather than modules that are being
> dlopen'd) you would further need to build the application so that it knows
> to look in that directory (this would be where rpath is used).
>
>>>   Unversioned shared libraries are bad, but inventing a library
>>> version can lead to conflicts with future upstream releases for public
>>> libraries, and is just not worth it at all for private ones. There's no need
>>> for a soname version if the library comes from the same package as the only
>>> user(s) of it.
>>>
>>>          Kevin Kofler
>> Looks fine to me. Anyone else? Should the private lib be filtered in
>> this situation?
>> Thanks for input.!
>>
> I would not consider this a hard and fast rule, but it is generally good
> advice.
>
> -Toshio

Thanks again. Following this advice when packaging makes perfect sense 
to me. Still, when reviewing, my question is how hard I should push it. 
If I understand Kevin correct I shouldn't push it all (?). Is your 
position  that  private, unversioned libs in /usr/lib* is a problem, but 
not a blocker?

>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120420/38535738/attachment.html>