Bug 601724 - rpmreaper permanently reports that perl packages are broken, while they don't seem to be
Summary: rpmreaper permanently reports that perl packages are broken, while they don't...
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: 12
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Panu Matilainen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-06-08 14:11 UTC by Petr Machata
Modified: 2015-05-05 01:35 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2010-09-30 17:42:15 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Petr Machata 2010-06-08 14:11:43 UTC
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 14:42:00 UTC
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 20:16:29 UTC
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 17:42:15 UTC
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.