Bug 75402

Summary: perl.req should not create requirements for simple .pl files.
Product: [Retired] Red Hat Linux Reporter: Aleksey Nogin <aleksey>
Component: rpmAssignee: Jeff Johnson <jbj>
Status: CLOSED DEFERRED QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 8.0CC: cturner
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2002-10-25 21:34:47 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Aleksey Nogin 2002-10-08 03:08:54 UTC
When building a Bugzilla RPM on 8.0, prel.req created such "dependencies" as:

        perl(bug_form.pl) is needed by bugzilla-2.17_2002.10.07-1
        perl(CGI.pl) is needed by bugzilla-2.17_2002.10.07-1        
        perl(globals.pl) is needed by bugzilla-2.17_2002.10.07-1

that were not matched by a perl.prov (despite the files actually being there).

Should perl.req be modified to omit "*.pl" dependencies?

Comment 1 Jeff Johnson 2002-10-25 19:14:33 UTC
Disable the generation of perl Requires: by
doing
	chmod -x /usr/lib/rpm/perl.req

The requirements should match provides, but
that assumes the package that has the provides
generated perl Provides: at the time it was built.
That isn't yet the case everywhere.

Comment 2 Aleksey Nogin 2002-10-25 19:57:14 UTC
> Disable the generation of perl Requires: 

Disabling the generation of perl requirements is *not* what is needed - most of
the requirements generated are correct.

> The requirements should match provides

Exactly, and this is what this bug is about! They do not match!

> that assumes the package that has the provides
> generated perl Provides:

of course, but this is irrelevant in this case since the "requirements" are
actually satisfied by the same package!

OK, let me try being more specific:
1) Create a package with two files: foo.pl and bar.pl
2) In bar.pl put a line:
requires "foo.pl";

Expected: the package does not have any "broken" perl dependencies.
Actual: the generated dependencies contain "perl(foo.pl)", that would not be
satisfied!

Example: bugzilla package (see the initial report).

Comment 3 Jeff Johnson 2002-10-25 21:23:08 UTC
There's little reason to generate Requires: for
Provides: that don't exist. We both seem to agree
here.

So why don't the matching Provides" exist? My
guess was that the packages had not (yet) been
built with a version of rpm that autogenerates
Provides:. Alternatively, perl.prov may be
deficient some how.

So what's needed: a rebuild of the package to autogenerate
the provides, or a deficiency of perl.prov?

Comment 4 Aleksey Nogin 2002-10-25 21:33:00 UTC
> My
> guess was that the packages had not (yet) been
> built with a version of rpm that autogenerates
> Provides:

Once again - there is no other package - we are talking about Requires: and
Provides: within the *same* *single* package.

> So what's needed: a rebuild of the package to autogenerate
> the provides, or a deficiency of perl.prov?

You can consider it to be a deficiency of perl.prov, but IMHO in this case it's
more of a deficiency of perl.req that generates something that is not really a
dependency!

Comment 5 Jeff Johnson 2002-10-25 22:30:07 UTC
Ah, got it, perl.req is mis-generating
dependencies. Yes, the regex's in
perl.req misfire sometimes. The fix
ATM is to override %__find_requires and
filter the erroneous autogenerated
dependencies. See some of the perl CPAN
packages for the technique.

Better yet (if you have the time) is
figger what patch is needed to perl.req,
only time and experience is gonna get
absolutely reliable perl dependencies.

There's no way to validate that a Provides:
for a given Requires: exists, either within
or outside a package, as dependencies are
open-ended.