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

[Toshio Kuratomi]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120420/c8292df9/attachment.sig>