Bugzilla will be upgraded to version 5.0 on December 2, 2018. The outage period for the upgrade will start at 0:00 UTC and have a duration of 12 hours
Bug 601724 - rpmreaper permanently reports that perl packages are broken, while they don't seem to be
rpmreaper permanently reports that perl packages are broken, while they don't...
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Panu Matilainen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-06-08 10:11 EDT by Petr Machata
Modified: 2015-05-04 21:35 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-09-30 13:42:15 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 Petr Machata 2010-06-08 10:11:43 EDT
Description of problem:
$ rpmreaper -l '~B'
perl-MooseX-Role-Parameterized-0.18-1.fc12.noarch
perl-namespace-autoclean-0.09-2.fc12.noarch
perl-Class-C3-0.22-1.fc12.noarch
perl-MooseX-MethodAttributes-0.19-1.fc12.noarch
perl-Moose-0.92-1.fc12.noarch
perl-HTTP-Body-1.07-1.fc12.noarch
perl-String-RewritePrefix-0.005-1.fc12.noarch
# ... and more in the same spirit

Package-clanup, on the other hand, seems to be quite content with the way the database is set up:

$ package-cleanup --problems 
Загруженные плагины:auto-update-debuginfo, dellsysidplugin2, refresh-packagekit
No Problems Found

Version-Release number of selected component (if applicable):
rpmreaper-0.1.6-2.fc12.x86_64

How reproducible:
Always.  FWIW it's been like that for a long time, perhaps even back to F 11.
Comment 1 Miroslav Lichvar 2010-07-28 10:42:00 EDT
This is a problem in librpm or the perl packages.

The packages have two requirements on rpmlib(VersionedDependencies), one is correctly marked with RPMSENSE_RPMLIB in flags, but the other isn't which means it won't be filtered out and rpmreaper will mark the package as broken because nothing provides rpmlib(VersionedDependencies).

In F13 and later this seems to be fixed.
Comment 2 Jeff Johnson 2010-07-28 16:16:29 EDT
Depending on the RPMSENSE_RPMLIB flag bit instead of just filtering all
dependencies that start "rpmlib(" cannot be supported or maintained,
largely because RPM is never upgraded and there are too many incompatibilities
already released (like the one here you have reported).

Fixed in F13 doesn't begin to really "fix" the issue.
Comment 3 Panu Matilainen 2010-09-30 13:42:15 EDT
The rpmlib() dependencies without RPMSENSE_RPMLIB bit set come from using the internal dependency generator as an external dependency generator (how hilarious is that...?), which is what the dependency filtering macros do. Rpm >= 4.8.0 goes to some lengths to fix the issue but it's not really worth backporting to older versions (and rebuilding the affected packages): this problem with using "rpmdeps" for dependency extraction is as old as "rpmdeps" itself (including all RHEL < 6 etc), so anything wanting to work with rpm < 4.8.0 needs to just manually filter dependencies starting with "rpmlib(" (or ask rpm about them).

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