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?