It's quite common that a package provides and requires the same thing. IMVHO the "requires" side is useless, and only clutters the dependency database. Wouldn't it be better if rpmbuild removed them? (It does not seem practical to solve this in the dependency generating scripts, as the algorithms for collecting provides and requires are usually independent.)
FWIW, http://thread.gmane.org/gmane.linux.rpm.maintenance/334 http://thread.gmane.org/gmane.linux.redhat.fedora.devel/95859 It has been pointed out that this would break --filerequires and --fileprovides, and would cause (more or less theoretical) problems with choosing between Providers of something in certain scenarios (see first message of the rpm-maint thread).
(In reply to comment #1) > this would break --filerequires and --fileprovides Er, s/break/remove some usefulness of/
There's no unambiguous way of determining that dependencies are local to a single package. Provides: cannot be eliminated without a guarantee that no other package anywhere has a Requires:. And both Provides: and Requires: are attached to files, not packages. Consider what happens when a file with a Provides: is not installed, where even the guarantee of "locally satisifed" is insufficient to determine whether a Requires: might be unnecessary. But have fun! You might even save 3-4Kb by attempting to filter out the "bloat"!
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 531300 has been marked as a duplicate of this bug. ***
reassigning it to rawhide - this is ongoing. I may implement part of this in yum/createrepo for the interim.
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
implemented in createrepo/yum. I'll leave it open and move up to f14 on rpm, though.
(In reply to comment #9) > implemented in createrepo/yum. I'll leave it open and move up to f14 on rpm, > though. Could you tell me more about this fix in createrepo/yum? Requires of package, which are provided by the same package are still problem during packaging. I can't imagine how this could be fixed in yum.
yum/createrepo remove self-provided requires from the repodata when it generates it. Then at least we're not including the obviously-provided requires so they don't clutter the repodata.
I believe this is the initial commit that implemented it in yum, it has been refined somewhat afterwards: http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=7ba8cd098fe2f915b8f8b6822066d23b59e3bff8
Okay time to close this - not going to happen in rpm. Like already noted here: 1) This would "break" --filerequire which is useful, if not exactly vital information. 2) Even self-requires are subject to what files are actually installed. Rpm in F >= 15 actually takes this into account (to some extent): when secondary arch binaries are "shadowed" by primary arch binaries, the secondary arch package does not actually provide the binary, so the apparent self-require becomes a dependency on another package. Ditto for replaced files. 3) Even ignoring 1) and 2), the space+bandwith+processing saving from this in rpm headers is neglible, its the re-re-re-repeatedly downladed repodata where such things become more expensive. Createrepo already filters them out (for better or worse)