Description of problem: Version-Release number of selected component (if applicable): iputils = 20121221-2.fc19 How reproducible: Steps to Reproduce: 1.repoquery -q --provides iputills 2.cat iputils.spec | grep Provides 3. Actual results: Results not mach Expected results: Additional info: And this situation persist on more packages ....
You can't compare spec and binary package dependencies like that. Even if you're looking at the spec of the exact version repoquery is coming up with, there are automatically generated dependencies added, spec conditionals may be present that affect what gets added and then there are sub-packages coming from the same spec. For example with current F19 iputils, here's what I see: [pmatilai@localhost iputils]$ grep Provides iputils.spec Provides: /bin/ping Provides: /bin/ping6 Provides: /sbin/arping Provides: /sbin/rdisc Provides: %{_sbindir}/ninfod [pmatilai@localhost iputils]$ [pmatilai@localhost iputils]$ repoquery -q --provides iputils /bin/ping /bin/ping6 /sbin/arping /sbin/rdisc config(iputils) = 20121221-2.fc19 iputils = 20121221-2.fc19 iputils(x86-64) = 20121221-2.fc19 [pmatilai@localhost iputils]$ The additional non-file provides are automatically generated, that is entirely normal. As for %{_sbindir}/ninfod, if you actually look at the spec, that provide doesn't belong to iputils at all: %package ninfod Group: System Environment/Daemons Summary: Node Information Query Daemon Requires: %{name} = %{version}-%{release} Provides: %{_sbindir}/ninfod NOTABUG for all I can tell, you need to look more carefully and be more specific if you think you're seeing an abnormal differences in the provides.