| Summary: | duplicate in package list | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Miroslav Lichvar <mlichvar> | ||||
| Component: | rpm | Assignee: | Panu Matilainen <pmatilai> | ||||
| Status: | CLOSED RAWHIDE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | low | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | rawhide | CC: | ffesti, jnovy, pmatilai | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-01-21 12:17:40 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Attachments: |
|
||||||
No, you're not supposed to do duplicate filtering. The semantics of rpmtsInitIterator() on an rpmdb index (such as RPMTAG_NAME) when called with NULL keyp changed in 4.9.x. Previously it silently fell back to RPMDBI_PACKAGES on that case, whereas it now walks the requested index (so for eg. obsoletes, it only returns the packages containing obsoletes instead of all). There's something fishy going on here, whether it's an old flaw exposed by the semantics change, a problem in the new code or some other quirk I dunno yet, I'll look into it. Thanks for spotting and reporting this. Aside from that: since rpmreaper always calls rpmtsInitIterator() with NULL keyp, ie "just give me all packages", you might as well use RPMDBI_PACKAGES directly (which is what rpm itself uses here, hence the difference) instead of RPMTAG_NAME. Ok, it's indeed a regression, related to the new automatic index population: the first package encountered on rebuilddb gets added twice to indexes. Will fix asap. Hum, actually there appear to be two different bugs here. The one in comment #2 only happens after --rebuilddb has been done, but something else is causing the iteration to return one duplicate even when the index correct. Okay, the second bug was an error in the iteration termination logic. Both issues should be fixed in rpm-4.9.0-0.beta1.3.fc15. Again, thanks for spotting and reporting this! Thanks for looking into this and for the suggestion to use the RPMDBI_PACKAGES index, it seems to be a bit faster now. Yup, using RPMDBI_PACKAGES is a tiny bit faster than going through secondary index when all the entries are being accessed. The indexes are only a win when looking up specific entires (eg by packages with certain name) and when not all packages have such entires (such as obsoletes). |
Created attachment 474476 [details] list rpm packages Description of problem: While testing rpmreaper with the new librpm, I've noticed one package was listed twice. The package was listed only once in the rpm -qa output, so I'm wondering if the client should be responsible for removing duplicities. With older librpm this didn't happen. A reproducer is attached. Version-Release number of selected component (if applicable): rpm-4.9.0-0.beta1.1.fc15.x86_64