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):
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
2. Upgrade this set of RPMS.
RPM continues rolling along after the first rpm fails.
I would like it to be configured such that if specified it will
rollback the transaction.
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
Created attachment 94309 [details]
Fixes problem with instance count passed to scriptlets
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
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 (-;
The patch has been worked into the HEAD of the rpm cvs, so from my
standpoint this bug can be marked as fixed.
Closing per the last comment