<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jul 22, 2015 at 2:32 PM, Ville Skyttä <span dir="ltr">&lt;<a href="mailto:ville.skytta@iki.fi" target="_blank">ville.skytta@iki.fi</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Wed, Jul 22, 2015 at 11:34 PM, Jason L Tibbitts III<br>
&lt;<a href="mailto:tibbs@math.uh.edu">tibbs@math.uh.edu</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;&gt;&gt; &quot;DJ&quot; == Dave Johansen &lt;<a href="mailto:davejohansen@gmail.com">davejohansen@gmail.com</a>&gt; writes:<br>
&gt;<br>
&gt; DJ&gt; rpmlint is outputting a private-shared-object-provides warning [1]<br>
&gt; DJ&gt; and I don&#39;t understand what the issue is or how I go about fixing<br>
&gt; DJ&gt; it. Any advice?<br>
&gt;<br>
&gt; It&#39;s pretty simple, really.  Your package has some sort of shared<br>
&gt; library for which RPM automatically generates a Provides: entry, but<br>
&gt; which is not actually installed in a path where it can be accessed as a<br>
&gt; system library.  This is usually because it&#39;s some sort of plugin.<br>
&gt;<br>
&gt; The solution is provided in the document to which you linked: set up<br>
&gt; filtering so that RPM does not generate the errant Provides: entry.<br>
<br>
</span>These Provides are generated for shared objects that have SONAMEs.<br>
SONAMEs on the other hand are about versioning, and for a lot of<br>
private shared objects they aren&#39;t used for anything and don&#39;t make<br>
sense in the first place, especially when they don&#39;t actually contain<br>
any versioning information. In such cases a better fix is to report<br>
the issue upstream and see if they&#39;d be willing to get rid of them. If<br>
that doesn&#39;t work or isn&#39;t applicable, then look into filtering out<br>
the Provides in the package build.<br>
</blockquote></div><br></div><div class="gmail_extra">Ok, that makes sense, but the part I&#39;m confused about is that this isn&#39;t a private library at all. It&#39;s /usr/lib64/libformat.so.1.1.0 and is intended for use by other applications. So is there something wrong in the .so that&#39;s causing rpmlint to think it&#39;s private?<br></div></div>