Bug 75402
Summary: | perl.req should not create requirements for simple .pl files. | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Aleksey Nogin <aleksey> |
Component: | rpm | Assignee: | Jeff Johnson <jbj> |
Status: | CLOSED DEFERRED | QA Contact: | |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 8.0 | CC: | 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
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. > 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). 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? > 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! 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. |