Bug 678605 - perl dependency extractor fails to filter unversioned deps when versioned exists
perl dependency extractor fails to filter unversioned deps when versioned exists
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
22
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Fedora Packaging Toolset Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks: requirements/rpm
  Show dependency treegraph
 
Reported: 2011-02-18 10:21 EST by Ville Skyttä
Modified: 2016-05-17 10:50 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-05-17 10:50:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ville Skyttä 2011-02-18 10:21:55 EST
http://koji.fedoraproject.org/koji/rpminfo?rpmID=2416489

Requires:
perl(Carp)
perl(Carp) >= 1.01
perl(constant)
perl(constant) >= 1.03

Code in perl.req should be filtering the unversioned ones out of the above, but for some reason it doesn't when actually building the package.  When invoking perl.req manually on the list of all the files in the package, the unversioned ones ("perl(Carp)" and "perl(constant)") are not output which is the behavior I'd expect.

Has the argument list to perl.req been changed in 4.9.0?  I can imagine this would happen if perl.req would be separately invoked for each file it should be invoked on.  I believe previously it was invoked only once per build and given a list of all files it should process as arguments.
Comment 1 Panu Matilainen 2011-02-21 01:38:47 EST
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.
Comment 2 Petr Pisar 2011-02-21 08:47:08 EST
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.
Comment 3 Petr Pisar 2011-02-21 08:51:20 EST
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.
Comment 4 Fedora Admin XMLRPC Client 2012-04-13 19:06:18 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 5 Fedora Admin XMLRPC Client 2012-04-13 19:09:26 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 6 Fedora End Of Life 2013-04-03 12:46:08 EDT
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
Comment 7 Fedora End Of Life 2015-01-09 11:34:39 EST
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.
Comment 8 Fedora End Of Life 2015-05-29 04:38:28 EDT
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.
Comment 10 Ľuboš Kardoš 2016-05-11 05:39:40 EDT
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.
Comment 11 Petr Pisar 2016-05-11 06:39:09 EDT
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).
Comment 12 Ľuboš Kardoš 2016-05-17 10:50:39 EDT
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

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