<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
On 04/20/2012 05:09 PM, Toshio Kuratomi wrote:
<blockquote cite="mid:20120420150925.GT28774@unaka.lan" type="cite">
<pre wrap="">On Fri, Apr 20, 2012 at 04:32:59PM +0200, Alec Leamas wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 04/20/2012 04:08 PM, Kevin Kofler wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> As far
as I know, invalid-soname does not match any requirement in our packaging
guidelines.
</pre>
</blockquote>
<pre wrap="">To my understanding, this is not really clear. From [1] I find (
thanks to tibbs):
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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).
</pre>
<blockquote type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap=""> 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
</pre>
</blockquote>
<pre wrap="">Looks fine to me. Anyone else? Should the private lib be filtered in
this situation?
Thanks for input.!
</pre>
</blockquote>
<pre wrap="">I would not consider this a hard and fast rule, but it is generally good
advice.
-Toshio</pre>
</blockquote>
<br>
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?<br>
<br>
<blockquote cite="mid:20120420150925.GT28774@unaka.lan" type="cite">
<pre wrap="">
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
</body>
</html>