[Fedora-packaging] Help with private-shared-object-provides from rpmlint

Dave Johansen davejohansen at gmail.com
Thu Jul 23 00:44:03 UTC 2015


On Wed, Jul 22, 2015 at 2:32 PM, Ville Skyttä <ville.skytta at iki.fi> wrote:

> On Wed, Jul 22, 2015 at 11:34 PM, Jason L Tibbitts III
> <tibbs at math.uh.edu> wrote:
> >>>>>> "DJ" == Dave Johansen <davejohansen at 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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/packaging/attachments/20150722/b91bc03c/attachment.html>


More information about the packaging mailing list