From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.17-14 i686) rpmtransAddPackage() removes packages obsoleted by the package being added. In order to prevent duplicate removal, it calls rpmdbPruneIterator() with the transaction's existing removed package list. The fourth argument to rpmdbPruneIterator() is 1, asserting that the pruning list is sorted; however, there does not appear to be any guarantee that the list is in fact sorted; removePackage() does not add dboffset in sorted order, nor is there a sort of the list somewhere in rpmtransAddPackage(). As a result, a package could be removed twice (which causes a silent error return in rpmRunTransactions()) due to failure to properly prune the set. Reproducible: Didn't try Steps to Reproduce: I noticed this problem by reading the source code, not by actually encountering it. Reliably producing the problem would be somewhat complicated because it is difficult to predict offsets of packages in the database, and bsearch() might find something in an unsorted list if it is lucky.
Yup, another good call, thanks. Fixed by moving the qsort from rpmdepCheck to removePackage in rpm-4.0.3-0.22.