Bug 675360 - rpmlint complain about private-shared-object-provides only on x86_64
rpmlint complain about private-shared-object-provides only on x86_64
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: rpmlint (Show other bugs)
14
Unspecified Unspecified
unspecified Severity low
: ---
: ---
Assigned To: Tom "spot" Callaway
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-02-05 00:07 EST by Ralf Corsepius
Modified: 2011-05-03 21:02 EDT (History)
5 users (show)

See Also:
Fixed In Version: rpmlint-1.2-1.fc14
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2011-04-30 23:27:03 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)
src-rpm to reproduce this issue (11.70 KB, application/x-redhat-package-manager)
2011-02-05 00:07 EST, Ralf Corsepius
no flags Details
mock build fc14.i686.rpm (12.57 KB, application/octet-stream)
2011-02-05 00:08 EST, Ralf Corsepius
no flags Details
mock-built fc14.x86_64.rpm (12.67 KB, application/x-redhat-package-manager)
2011-02-05 00:08 EST, Ralf Corsepius
no flags Details

  None (edit)
Description Ralf Corsepius 2011-02-05 00:07:05 EST
Created attachment 477162 [details]
src-rpm to reproduce this issue

Description of problem:
rpmlint complains about "private-shared-object-provides" on a perl-modules's shared libraries on x86_64, but doesn't do so i686.

Version-Release number of selected component (if applicable):
rpmlint-1.0-2.fc14.noarch

How reproducible:
Always.

Steps to Reproduce:
1. rebuild the srpm from the attachment in mock for i686 and x86_64
2. run rpmlint on the resulting rpms.
  
Actual results:
# rpmlint perl-Digest-JHash-0.07-1.fc14.x86_64.rpm \
  perl-Digest-JHash-0.07-1.fc14.i686.rpm 
perl-Digest-JHash.x86_64: W: private-shared-object-provides /usr/lib64/perl5/auto/Digest/JHash/JHash.so JHash.so()(64bit)
2 packages and 0 specfiles checked; 0 errors, 1 warnings.


Expected results:
rpmlint to produce arch-independent results, i.e. either always complain or never.
Comment 1 Ralf Corsepius 2011-02-05 00:08:21 EST
Created attachment 477163 [details]
mock build fc14.i686.rpm
Comment 2 Ralf Corsepius 2011-02-05 00:08:59 EST
Created attachment 477164 [details]
mock-built fc14.x86_64.rpm
Comment 3 Ralf Corsepius 2011-02-05 02:30:42 EST
From what I can gather from the sources, the origin of this issue is rpmlint not taking into account the paths being valid on the host architecture, but only the paths of the build architecture. 

I.e. when running rpmlint on an x86_64 to check i686-packages, its appears to check the package against the library paths being valid on x86_64's.
Comment 4 Ville Skyttä 2011-02-05 03:27:18 EST
Actually it's the other way around, rpmlint expands %perl_vendorarch and friends on the system it is running on (no matter what the package's architecture is) and triggers private-shared-object-provides only for those dirs.  I don't think there's a very good way to fix this (rpmlint doesn't know what %perl_vendorach and friends might expand to on other systems), but this is now improved upstream somewhat and now it catches your test case.

http://rpmlint.zarb.org/cgi-bin/trac.cgi/changeset/1835
Comment 5 Ralf Corsepius 2011-02-05 07:30:20 EST
(In reply to comment #4)
> Actually it's the other way around, rpmlint expands %perl_vendorarch and
> friends on the system it is running on (no matter what the package's
> architecture is)
I sense a miscommunication, and believe we actually wanted to express the same:

I was using autoconf-terms:

host ... system to build for (in rpm's nomenclature: target)

build ... native system a process is running on (in rpms's nomenclature: host)

> and triggers private-shared-object-provides only for those
> dirs.  I don't think there's a very good way to fix this (rpmlint doesn't know
> what %perl_vendorach and friends might expand to on other systems), but this is
> now improved upstream somewhat and now it catches your test case.

The only way I can imagine is to equippe rpmlint with a lookup table containing all host's settings and let rpmlint use an rpm's %arch to retrieve arch-dependent paths.
Comment 6 Fedora Update System 2011-04-24 22:09:51 EDT
rpmlint-1.2-1.fc14 has been submitted as an update for Fedora 14.
https://admin.fedoraproject.org/updates/rpmlint-1.2-1.fc14
Comment 7 Fedora Update System 2011-04-24 22:10:18 EDT
rpmlint-1.2-1.fc15 has been submitted as an update for Fedora 15.
https://admin.fedoraproject.org/updates/rpmlint-1.2-1.fc15
Comment 8 Fedora Update System 2011-04-24 22:10:45 EDT
rpmlint-1.2-1.fc13 has been submitted as an update for Fedora 13.
https://admin.fedoraproject.org/updates/rpmlint-1.2-1.fc13
Comment 9 Fedora Update System 2011-04-25 16:54:12 EDT
Package rpmlint-1.2-1.fc14:
* should fix your issue,
* was pushed to the Fedora 14 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing rpmlint-1.2-1.fc14'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/rpmlint-1.2-1.fc14
then log in and leave karma (feedback).
Comment 10 Fedora Update System 2011-04-30 23:26:36 EDT
rpmlint-1.2-1.fc15 has been pushed to the Fedora 15 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 11 Fedora Update System 2011-05-03 21:00:07 EDT
rpmlint-1.2-1.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 12 Fedora Update System 2011-05-03 21:01:28 EDT
rpmlint-1.2-1.fc14 has been pushed to the Fedora 14 stable repository.  If problems still persist, please make note of it in this bug report.

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