Description of problem: In its present form if an error occurs in one of the scriptlets of an rpm, RPM will continue trying to install the other transaction elements of the transaction. It is understood why this is the default behaviour, but for some environments (think CGL) its not desirable. It would be good if rpm could be set to rollback a transaction if it failed. Version-Release number of selected component (if applicable): 4.2-0.69 How reproducible: Very Steps to Reproduce: 1. Create an a few rpms, one of which fails in %pre or %post. Be careful to make sure that the other rpms depend on the broken one. 2. Upgrade this set of RPMS. Actual results: RPM continues rolling along after the first rpm fails. Expected results: I would like it to be configured such that if specified it will rollback the transaction. Additional info:
Created attachment 91862 [details] Patch to cause rpm to conditioinally rollback a transaction on a failure. Here are things that are not right yet: - failed rpms are not rolled back (i.e. failure in %post), but the rest still are. Saved for a future enhancement. - I am only finding the repackaged package by the current transaction elements NEVRA; I should be checking REMOVETID against INSTALLTID, but I figured I would save that for a future enhancement.
Created attachment 92245 [details] The one that works (-; Finally, got it working. The main change is I am actually looking in the repackage dir with IDTXglob() and matching REMOVETID's to INSTALLTID's. Course there were other changes. You can pick up a test harness fo this at: http://lee.k12.nc.us/~joden/misc/patches/rpm/ Thanks...james
Created attachment 94309 [details] Fixes problem with instance count passed to scriptlets Hi Jeff, I got the instance counts correct when running an autorollback. This required me to generate another little data structure called rpmtsScore that kept a status of the state of an rpm by name (not NEVR). With this information available to the autorollback transaction I could make the proper adjustments to the instance counts. Its a whole lot more complicated than that (I sure wish I could have figured out a way to make it simpler), so I will attach a little note that in detail describes what I did to make the scriptlet count correct in an autorollback.
Created attachment 94310 [details] Description of instance count correction algorithm used with autorollback transactions.
Created attachment 95146 [details] I broke --test with the patch...its fixed now. This revised patch disables the building of the auto-rollback transaction if the transaction is being run in test mode (i.e. --test was specified on the cli). I also had a typo on my transaction type flags (-; Cheers...james
The patch has been worked into the HEAD of the rpm cvs, so from my standpoint this bug can be marked as fixed. Cheers...james
Closing per the last comment