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?
Disable the generation of perl Requires: by
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.
> 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:
Expected: the package does not have any "broken" perl dependencies.
Actual: the generated dependencies contain "perl(foo.pl)", that would not be
Example: bugzilla package (see the initial report).
There's little reason to generate Requires: for
Provides: that don't exist. We both seem to agree
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?
> guess was that the packages had not (yet) been
> built with a version of rpm that autogenerates
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
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