https://bugzilla.redhat.com/show_bug.cgi?id=1216279#c7 In the above review, rpmlint is outputting a private-shared-object-provides warning [1] and I don't understand what the issue is or how I go about fixing it. Any advice? Thanks, Dave
[1]: https://fedoraproject.org/wiki/Common_Rpmlint_issues?rd=PackageMaintainers/C...
"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.
- J<
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.
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?
On Thu, Jul 23, 2015 at 3:44 AM, Dave Johansen davejohansen@gmail.com wrote:
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?
My rpmlint-1.7-1.fc22.noarch on a x86_64 F22 box does not output that warning for your package in the first place.
On Wed, Jul 22, 2015 at 11:28 PM, Ville Skyttä ville.skytta@iki.fi wrote:
On Thu, Jul 23, 2015 at 3:44 AM, Dave Johansen davejohansen@gmail.com wrote:
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?
My rpmlint-1.7-1.fc22.noarch on a x86_64 F22 box does not output that warning for your package in the first place.
This warning is only showing up when running rpmlint on the installed package during fedora-review. The man package indicates that the set of checks done on installed binary packages is a superset of the one run on uninstalled binary package files.
On Thu, Jul 23, 2015 at 6:35 PM, Dave Johansen davejohansen@gmail.com wrote:
On Wed, Jul 22, 2015 at 11:28 PM, Ville Skyttä ville.skytta@iki.fi wrote:
My rpmlint-1.7-1.fc22.noarch on a x86_64 F22 box does not output that warning for your package in the first place.
This warning is only showing up when running rpmlint on the installed package during fedora-review. The man package indicates that the set of checks done on installed binary packages is a superset of the one run on uninstalled binary package files.
That's correct. But my rpmlint doesn't output that warning on the installed package either. I haven't tested fedora-review on it.
On Thu, Jul 23, 2015 at 1:26 PM, Ville Skyttä ville.skytta@iki.fi wrote:
On Thu, Jul 23, 2015 at 6:35 PM, Dave Johansen davejohansen@gmail.com wrote:
On Wed, Jul 22, 2015 at 11:28 PM, Ville Skyttä ville.skytta@iki.fi
wrote:
My rpmlint-1.7-1.fc22.noarch on a x86_64 F22 box does not output that warning for your package in the first place.
This warning is only showing up when running rpmlint on the installed package during fedora-review. The man package indicates that the set of checks done on installed binary packages is a superset of the one run on uninstalled binary package files.
That's correct. But my rpmlint doesn't output that warning on the installed package either. I haven't tested fedora-review on it.
Ok, sorry for the mistake.
But anyways, the comment was from the review so I assumed it was valid, but I just ran fedora-review on F21 and I can't reproduce the issue, so I'll ask the review how this warning was produced.
Thanks, Dave
On Sat, Jul 25, 2015 at 11:43 AM, Dave Johansen davejohansen@gmail.com wrote:
On Thu, Jul 23, 2015 at 1:26 PM, Ville Skyttä ville.skytta@iki.fi wrote:
On Thu, Jul 23, 2015 at 6:35 PM, Dave Johansen davejohansen@gmail.com wrote:
On Wed, Jul 22, 2015 at 11:28 PM, Ville Skyttä ville.skytta@iki.fi
wrote:
My rpmlint-1.7-1.fc22.noarch on a x86_64 F22 box does not output that warning for your package in the first place.
This warning is only showing up when running rpmlint on the installed package during fedora-review. The man package indicates that the set of checks done on installed binary packages is a superset of the one run on uninstalled binary package files.
That's correct. But my rpmlint doesn't output that warning on the installed package either. I haven't tested fedora-review on it.
Ok, sorry for the mistake.
But anyways, the comment was from the review so I assumed it was valid, but I just ran fedora-review on F21 and I can't reproduce the issue, so I'll ask the review how this warning was produced.
I just updated to F22 and I can now reproduce this issue. Do I need to open a bugzilla? Or is there further investigation that I should do first?
On Tue, Aug 4, 2015 at 6:12 AM, Dave Johansen davejohansen@gmail.com wrote:
I just updated to F22 and I can now reproduce this issue. Do I need to open a bugzilla? Or is there further investigation that I should do first?
Sure, if the warning is bogus, please open one. I think enough investigation is finding out whether it happens with plain rpmlint or only with fedora-review and then choose the component to report against as appropriate.
packaging@lists.fedoraproject.org
-
Dave Johansen -
Jason L Tibbitts III -
Ville Skyttä