Bug 678605

The internal dependency generator always ran separately for each file of a given type, whereas the external dependency generator gets the entire file list passed to it. This hasn't changed between 4.8 and 4.9.

This is not problem of Perl only. rpmbuild should minimize the dependency set automatically at the last step just before writing them to binary package. It would help a lot.

Currently we do awfull things like

%filter_from_provides /^perl(Carp)$/d

which could break the set if upstream stops to require exact version perl(Carp) >= 1.01. Then we will remove the only perl(Carp) requires silently which is not good.

And yet another problem. Sometimes I can see `perl(Carp)  ' dependency. The values should be normalized before passing them to %filter_* macro and before writing them to binary package. Catching whitespaces in regular expression is night mare especially if `rpm -q' does not delimit them.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

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

This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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.

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. 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 EOL if it remains open with a Fedora  'version'
of '20'.

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.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 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, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

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.

http://koji.fedoraproject.org/koji/rpminfo?rpmID=5545357

As Panu said he internal dependency generator always ran separately for each file. You can also find out which dependency comes from which file with --filerequire/--fileprovide options:

$ rpm -q --filerequire -p perl-CSS-DOM-0.15-6.fc22.noarch.rpm | grep "perl(Carp)"
/usr/share/perl5/vendor_perl/CSS/DOM/Parser.pm	perl(CSS::DOM) perl(CSS::DOM::Rule::Style) perl(CSS::DOM::Style) perl(CSS::DOM::Util) perl(Carp) >= 1.01 perl(re) perl(strict)
/usr/share/perl5/vendor_perl/CSS/DOM/Rule.pm	perl(CSS::DOM::Constants) perl(CSS::DOM::Exception) perl(Carp) perl(Exporter) >= 5.57 perl(Scalar::Util) perl(constant) >= 1.03 perl(strict) perl(warnings)
/usr/share/perl5/vendor_perl/CSS/DOM/Value.pm	perl(CSS::DOM::Constants) perl(Carp) perl(Exporter) >= 5.57 perl(constant) >= 1.03 perl(strict) perl(warnings)
/usr/share/perl5/vendor_perl/CSS/DOM/Value/Primitive.pm	perl(CSS::DOM::Util) perl(Carp) perl(Exporter) >= 5.57 perl(constant) >= 1.03 perl(strict) perl(warnings)

By merging dependencies in rpm header we would lose this mapping between files and dependencies. So I want to ask why do you need this? Do you have some real problem with this like problem with dependency solving? If the only problem is ugly output of "rpm -q --requires ..." then we could only merge dependencies in that output but not in the header.

I did not know an RPM header lists the dependencies for each file separately.

Is this information useful? It sounds to me more like a debugging log that should be written into build.log than to the RPM package. Consider there are explicit dependencies (Requires tags in spec files) that do not posses this capability. And then there are generated dependency filters (__requires_exclude) that also cannot be constrained to a specific file or even a binary package.

The reason for merging the dependencies is honorable reviewers thinks redundant dependencies are a bug. E.g. <https://bugzilla.redhat.com/show_bug.cgi?id=963903#c3>. They think it bloats repository database and prolongs dependency resolution.

If you insist the per-file dependencies are useful and packagers should not remove inferior or duplicate dependencies from packages (this is current practice in Perl), then please consider minimizing the dependency list when creating repository database (createrepo_c).

Ok, I reconsidered this and I fixed this upstream [1] and also in the rawhide [2].

[1] https://github.com/rpm-software-management/rpm/commit/6ac793b215ac8d9db99d9632cbf71b014c7ffee0
[2] http://koji.fedoraproject.org/koji/buildinfo?buildID=766170