Description of problem:
Consider the following snippet:
print STDOUT << "USAGE";
use non-standard port number for connection
This will result in perl(non-standard) as a requirement.
Version-Release number of selected component (if applicable):
$ rpm -q perl
$ rpm -q rpm
$ rpm -q rpm-build
Steps to Reproduce:
1. Put mentioned snippet into file test.pl
2. /usr/lib/rpm/perl.req test.pl
Will show perl(non-standard) as a requirement.
Should not give perl(non-standard) as a requirement
Yep, the regexes in perl.req are fragile and will generate dependencies for tokens found after "use".
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.
FWIW, the patch in bugzilla #198033 fixes a major class of problems extracting tokens after "use" in
Looks like bug #198033 is a separate-but-similar issue, correct? I'm going to
move this to devel -- if anyone thinks otherwise please correct me.
Yup, the patch in #198033 doesn't help with this one even if it's similar.
Reassigning to owner after bugzilla made a mess, sorry about the noise...
This one is dangling around for quite some time now. I didn't package any Perl
modules lately but doing the described test above still returns the wrong
answer. Are you going to fix this or should we close this as WONTFIX?
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
There is a workaround described at http://fedoraproject.org/wiki/Packaging/Perl
so I'll close this WONTFIX. If you disagree please re-open, but this has been
open for a very long time now...
Actually, I just tried this out with the rpm-build-220.127.116.11-2.fc9 perl.req, and
it does not output "perl(non-standard)" (or anything else, on a very basic test
script). I couldn't even say offhand whether it's my aforementioned #198033
patch that fixes it! But it seems to work, one way or another.