Bug 983596 - Old dependency filter breaks file coloring
Summary: Old dependency filter breaks file coloring
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: libpst
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Carl Byington
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: F-ExcludeArch-ppc64le, PPC64LETracker
TreeView+ depends on / blocked
 
Reported: 2013-07-11 14:17 UTC by Petr Pisar
Modified: 2014-03-20 18:05 UTC (History)
3 users (show)

Fixed In Version: libpst-0.6.63-1.fc21
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-03-20 18:05:20 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

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


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