Red Hat Bugzilla – Bug 35828
rpmtrans interface doesn't check for duplicate removals
Last modified: 2007-04-18 12:32:39 EDT
From Bugzilla Helper: User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.2.17-14 i686) I have a home-grown program which attempts to migrate a system from one list of RPMs to another list (perhaps preserving locally added or removed or upgraded RPMs if the machine is marked as privately owned). It uses rpmtransAddPackage() and rpmtransRemovePackage(), then does a dependency check and ordering, and then calls rpmRunTransactions(). Sometimes one of the packages to be added has an "Obsoletes" declaration for one of the packages which was to be removed. In this case, rpmtransAddPackage() removes the package, and then I wind up removing it myself with rpmtransRemovePackage(), so there are now two removal operations for the same package. When rpmRunTransactions() tries to execute the second removal, it fails to find the db offset in the interface, increments the error count, and eventually returns an error status (without ever having printed an error message, so I had to pull out the debugger to diagnose the error return). It would seem prudent for rmplib to check internally for duplicate package removals. Barring that, it would be nice (to say the least) if rpmlib had a mechanism for the application to avert duplicate removals. Internally, rpmlib references the transaction's removedPackages array, but that mechanism is not available to the application since transaction sets are an opaque type. Reproducible: Always Steps to Reproduce: Write a program which adds and removes packages using the rpmtrans interface, and try to use it.
Hmmm, the problem is much worse than obsoletes, as this is the ximian destroying databases problem AFAICT. FIxed in rpm-4.0.3-0.22, thanks for another astute call.