Bug 983596

Summary: Old dependency filter breaks file coloring
Product: [Fedora] Fedora Reporter: Petr Pisar <ppisar>
Component: libpstAssignee: Carl Byington <carl>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: carl, dan, ppisar
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: libpst-0.6.63-1.fc21 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-20 18:05:20 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:
Embargoed:
Bug Depends On:    
Bug Blocks: 1051573    

Description Petr Pisar 2013-07-11 14:17:55 UTC
Current spec file uses old RPM dependency filtering method:

%{?filter_setup:
%filter_provides_in %{python_sitearch}/_.*\.so$
%filter_setup
}

This one is not compatible with RPM file coloring needed for proper multilib support. See <https://bugzilla.redhat.com/show_bug.cgi?id=729536#c4> for more details.

Please rewrite the filter to new method. E.g.:

%global __provides_exclude_from %{?__provides_exclude_from:%__provides_exclude_from|}^%{python_sitearch}/_.*\.so$

This is the difference in resulting binary package:

petr@dhcp-0-146:~/fedora/libpst/x86_64 $ rpm -q --filecolor -p libpst-0.6.59-1.fc19.x86_64.rpm 
/usr/bin/lspst  (none)
/usr/bin/nick2ldif      (none)
/usr/bin/pst2dii        (none)
/usr/bin/pst2ldif       (none)
/usr/bin/readpst        (none)
/usr/share/man/man1/lspst.1.gz  (none)
/usr/share/man/man1/pst2dii.1.gz        (none)
/usr/share/man/man1/pst2ldif.1.gz       (none)
/usr/share/man/man1/readpst.1.gz        (none)
/usr/share/man/man5/outlook.pst.5.gz    (none)
petr@dhcp-0-146:~/fedora/libpst/x86_64 $ rpm -q --filecolor -p libpst-0.6.59-2.fc19.x86_64.rpm 
/usr/bin/lspst  2
/usr/bin/nick2ldif      2
/usr/bin/pst2dii        2
/usr/bin/pst2ldif       2
/usr/bin/readpst        2
/usr/share/man/man1/lspst.1.gz  0
/usr/share/man/man1/pst2dii.1.gz        0
/usr/share/man/man1/pst2ldif.1.gz       0
/usr/share/man/man1/readpst.1.gz        0
/usr/share/man/man5/outlook.pst.5.gz    0

Comment 1 Fedora End Of Life 2013-09-16 14:29:45 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20

Comment 2 Carl Byington 2013-09-23 01:11:15 UTC
Something is wrong with that:

%global __provides_exclude_from %{?__provides_exclude_from:%__provides_exclude_from|}^%{python_sitearch}/_.*\.so$

error: Macro %__provides_exclude_from has empty body
error: line 44: Unknown tag: ^/usr/lib64/python2.7/site-packages/_.*\.so$
error: query of specfile /home/carl/fedora/libpst/libpst.spec failed, can't parse

Could not execute build: need more than 0 values to unpack

Comment 3 Petr Pisar 2013-09-23 08:54:36 UTC
(In reply to Carl Byington from comment #2)
> Something is wrong with that:
> 
> %global __provides_exclude_from
> %{?__provides_exclude_from:%__provides_exclude_from|}^%{python_sitearch}/_.
> *\.so$
> 
> error: Macro %__provides_exclude_from has empty body
> error: line 44: Unknown tag: ^/usr/lib64/python2.7/site-packages/_.*\.so$
> error: query of specfile /home/carl/fedora/libpst/libpst.spec failed, can't
> parse
> 
> Could not execute build: need more than 0 values to unpack

I can see different code in your spec file:

%global __provides_exclude_from
%{?__provides_exclude_from:%__provides_exclude_from|}^%{python_sitearch}/_.*\.so$

New lines are important in the spec language.

Comment 4 Dan HorĂ¡k 2014-03-20 18:01:53 UTC
oh, bad bugzilla, it breaks what should be on one line into 2 lines :-)

@@ -40,8 +40,7 @@ Requires:           python
 Requires:           %{name}-libs = %{version}-%{release}
 
 %if 0%{?fedora} >= 20
-%global __provides_exclude_from
-%{?__provides_exclude_from:%__provides_exclude_from|}^%{python_sitearch}/_.*\.so$
+%global __provides_exclude_from %{?__provides_exclude_from:%__provides_exclude_from|}^%{python_sitearch}/_.*\.so$
 %else
 %{?filter_setup:
 %filter_provides_in %{python_sitearch}/_.*\.so$


fixes the problem