Description of problem:
$ rpmreaper -l '~B'
# ... 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):
Always. FWIW it's been like that for a long time, perhaps even back to F 11.
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.
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.
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).