Bug 235486 - rpmlint gives false errors on sonames with a - in them
rpmlint gives false errors on sonames with a - in them
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: rpmlint (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Ville Skyttä
Fedora Extras Quality Assurance
:
: 436497 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-04-06 02:06 EDT by Hans de Goede
Modified: 2008-03-07 13:19 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-04-06 14:40:35 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2007-04-06 02:06:17 EDT
I happened to stumble over this when looking at something completely else, and I
thought it would be a good idea to report this, when rpmlint gets run on gnucash
it says:

E: gnucash invalid-soname /usr/lib/libgncqof-backend-qsf.so libgncqof-backend-
qsf.so
E: gnucash invalid-soname /usr/lib/libgnc-backend-file.so libgnc-backend-file.so

This is from https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=222388#c4

Quoting from this comment: "I think rpmlint can't handle things with - in the
filename when it's not a major version number."
Comment 1 Ville Skyttä 2007-04-06 12:34:02 EDT
The issue is not dashes in sonames, but that rpmlint wants *versioned* sonames.

$ rpmlint -I invalid-soname
invalid-soname :
The soname of the library is neither of the form lib<libname>.so.<major> or
lib<libname>-<major>.so.

The regular expression used to test this is ^lib.+(\.so\.[\.0-9]+|-[\.0-9]+\.so)$

As far as I understand, the purpose of sonames is to provide versioning
information, and if that's correct, I don't see why rpmlint should not flag
unversioned ones as erratic.

OTOH, that code was not written by me and the rpmlint source doesn't provide
sufficient information to judge the intent unambiguously, and I'm not an expert
enough on sonames and related things to be able to tell for sure.

On a related note, rpmlint does the soname "validity" check on filenames
matching "/lib(64)?/[^/]+\.so(\.[0-9]+)*$" only, which implies to me that the
intent of that check is to restrict it to system libdirs only, and not check
*.so modules in app specific dirs (which are often unversioned).

So perhaps in the gnucash case the right thing to do would be to install those
unversioned libgnc*.so to gnucash's private lib dirs instead of /usr/lib?

Anyway, if I'm even remotely correct, "invalid-soname" is not a good name for
the message though, "unversioned-soname" would be better, if that's the
intention.  Or perhaps "unversioned-soname-in-system-libdir".

See also http://en.wikipedia.org/wiki/Soname and the linuxquestions.org link
there.  Thoughts?
Comment 2 Hans de Goede 2007-04-06 14:40:35 EDT
(In reply to comment #1)
> The issue is not dashes in sonames, but that rpmlint wants *versioned* sonames.
> 

Ah, my bad, I just stumbled over this while looking for reviews with gconf
schema in the text, and thought I should file it. But it seems that the person
making the comment was wrong, and rpmlint is doing the right thing.

> As far as I understand, the purpose of sonames is to provide versioning
> information, and if that's correct, I don't see why rpmlint should not flag
> unversioned ones as erratic.
> 

Agreed, closing as invalid.

> So perhaps in the gnucash case the right thing to do would be to install those
> unversioned libgnc*.so to gnucash's private lib dirs instead of /usr/lib?
> 

Yes I think it would.

> Anyway, if I'm even remotely correct, "invalid-soname" is not a good name for
> the message though, "unversioned-soname" would be better, if that's the
> intention.  Or perhaps "unversioned-soname-in-system-libdir".
> 

Yes that would be better.
Comment 3 Ville Skyttä 2008-03-07 13:19:03 EST
*** Bug 436497 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.