On Wed, Jul 22, 2015 at 2:32 PM, Ville Skyttä <ville.skytta@iki.fi> wrote:
On Wed, Jul 22, 2015 at 11:34 PM, Jason L Tibbitts III
<tibbs@math.uh.edu> wrote:
>>>>>> "DJ" == Dave Johansen <davejohansen@gmail.com> writes:
>
> DJ> rpmlint is outputting a private-shared-object-provides warning [1]
> DJ> and I don't understand what the issue is or how I go about fixing
> DJ> it. Any advice?
>
> It's pretty simple, really.  Your package has some sort of shared
> library for which RPM automatically generates a Provides: entry, but
> which is not actually installed in a path where it can be accessed as a
> system library.  This is usually because it's some sort of plugin.
>
> The solution is provided in the document to which you linked: set up
> filtering so that RPM does not generate the errant Provides: entry.

These Provides are generated for shared objects that have SONAMEs.
SONAMEs on the other hand are about versioning, and for a lot of
private shared objects they aren't used for anything and don't make
sense in the first place, especially when they don't actually contain
any versioning information. In such cases a better fix is to report
the issue upstream and see if they'd be willing to get rid of them. If
that doesn't work or isn't applicable, then look into filtering out
the Provides in the package build.

Ok, that makes sense, but the part I'm confused about is that this isn't a private library at all. It'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's causing rpmlint to think it's private?