Bug 1309664

Summary:	Wrongly generated provides from a private shared library without a SONAME
Product:	[Fedora] Fedora	Reporter:	Petr Pisar <ppisar>
Component:	rpm	Assignee:	Packaging Maintenance Team <packaging-team-maint>
Status:	CLOSED WONTFIX	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	22	CC:	cweyl, iarnell, jplesnik, jzeleny, kasal, lkardos, novyjindrich, packaging-team-maint, perl-devel, pknirsch, ppisar, psabata, rc040203, tcallawa
Target Milestone:	---	Keywords:	Regression
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-03-11 11:51:28 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Petr Pisar 2016-02-18 11:59:03 UTC

I noticed perl-IPTables-libiptc package started to provide "libiptc.so()(64bit)" RPM symbol. The package contains libiptc.so file that is a shared library, but the library is in a non-public location and does not defined any SONAME. Therefore I think this is a bug in the rpm.

This regression is triggered by upgrading rpmbuild from 4.11.1-6.fc21 to 4.11.2-11.fc21 as can bee seen in root.log files of perl-IPTables-libiptc-0.52-7.fc21 (last correct build) and perl-IPTables-libiptc-0.52-9.fc21 (first broken build).

$ echo libiptc.so | /usr/lib/rpm/rpmdeps --provides 
libiptc.so()(64bit)

$ scanelf --soname  libiptc.so 
 TYPE   SONAME FILE 
ET_DYN  libiptc.so 

If I rename the libiptc.so to a.so, the /usr/lib/rpm/rpmdeps stops providing the RPM symbol. Also note that the libiptc.so links to libiptc.so.0:

$ scanelf --needed libiptc.so 
 TYPE   NEEDED FILE 
ET_DYN libdl.so.2,libnsl.so.1,libiptc.so.0,libip4tc.so.0,libxtables.so.10,libperl.so.5.22,libc.so.6 libiptc.so

Comment 1 Ľuboš Kardoš 2016-03-09 13:29:31 UTC

RPM didn't changed its behaviour in this way between versions 4.11.1-6.fc21 and 4.11.2-11.fc21. What changed are macros in the package perl-macros. The change was done between versions 5.18.1-287.fc20 and 5.18.2-299.fc21. Specifically there is a change in the macro %__provides_exclude_from, the part responsible for filtering out the file /usr/lib64/perl5/vendor_perl/auto/IPTables/libiptc/libiptc.so is missing in the newer version of the perl-macros package.

perl-macros-5.18.1-287.fc20:
%global __provides_exclude_from %{perl_vendorarch}/auto/.*\\\\.so$|%{perl_archlib}/.*\\\\.so$|%{_docdir}

perl-macros-5.18.2-299.fc21:
%global __requires_exclude_from %{?__requires_exclude_from:%__requires_exclude_from|}^%{_docdir}

So the regression is in the perl-macros package. Reassigning to perl.



And why these provides are created by rpm? It seems there was an attempt to disable them but it was unsuccessful, For details see:

https://github.com/rpm-software-management/rpm/commit/b6f159a34c946b75cb95a7862968ff4e8eb74fe6

Comment 2 Petr Pisar 2016-03-09 16:06:30 UTC

I removed the from perl-macros because at rpmbuild did not autogenerate fake SONAMES from private libraries at that time. Since it's not true anymore (and reading the commit shows elfdeps changed default behavior), I will add the filter back into perl_default_filter macro. It would be great if these experiments were better communicated in the future.

Comment 3 Petr Pisar 2016-03-11 11:51:28 UTC

I tracked down the commit that removed the filter from perl_default_filter:

commit c954fb6e868302112aae1d375724d08d3d35cf20
Author: Petr Písař <ppisar>
Date:   Tue Oct 22 08:47:11 2013 +0200

    perl_default_filter macro does not filter private libraries from provides

And there is link to FPC decision <https://fedorahosted.org/fpc/ticket/353> that explicitly requires to remove the filter because rpm-build should not generate the dependency.

Therefore this is not a bug in the perl_default_filter.

At the end I did not reportd it does not work in general. I reported it does not work for libFOO.so-named library files that do not define DT_SONAME. And that looks like deliberate rpm decision to keep synthesize the Provides from these files.

Therefore I move this bug to rpm component as the feature and the decision really comes from the rpm-build. I will recommend packagers to handle this cases explicitly in their spec files.