Hi All, I have been using rpm with my autorollback pactch for a while now and things have been going just fine, but today I noticed a problem. Before explain the problem let me explain one of the two primary reasons I was driven to write this patch, which help me explain the problem. Basically, I realized about a year ago, that when any package in an rpm transaction fails (i.e. from %pre forward), that transaction after it is finished will not be recorded as having happened in the rpm database (the headers from any successfully installed packages will be there though (-;). This becomes quite a problem if you want to use rpm's transactional rollback feature to undo this borked transaction, because according to the rpm database the transaction did not happen. My solution to dealing with this problem (and the fact that I wanted the transaction to stop as soon as an error occured), was to create the autorollback patch. It basically builds a transaction of the successfully installed packages as they are installed, and if an error occurs it rolls what has been sucessfully installed back out. Now here is the problem, the failed transactions TID does not get recorded but if they rollback transaction goes off without a hitch then its TID does get recorded. That's fine as long as you only wanted the failed transaction to be rolled back, but if you later (or right after rpm is done) wanted to use rpm's "normal" rollback feature to rollback to time before the failed transaction occured, then you hit a problem. Take simple example. You first install a set of rpms successfully (we'll call this T1). Then you install the next set, T2, but it fails, so the autorollback transaction T3 kicks in. Now the rpm database only has T1 and T3 recorded, so if you decide to rollback to time before T1 was applied, rpm will: - rollback T3, which effectively undoes your autorollback transaction. - rollback T1. The end result is you end up with some rpms from T2 still on the system; in other words your system is borked (you can recover from this, but is a severe pain). After talking with some coworkers about this, we came to the conclusion that the best path was to make the autorollback transaction (T3 in the example above) not be recorded in the database either. The result would be that when you tried to rollback to time before T1 you would get the results you want (that is only T1 would be rolled back because T2 was already rolled back, and T3 was just the agent to clean up the broken T2 transaction). Also, this would allow the autorollback feature to not break the N-level rollback feature of standard rpm. All this said, does this seem to be a sane path, or the right thing to do? Is there a better way? Thanks for any input...james P.S. We did also consider adding the ability to provide in addition to the rollback date an upper bond, such that rpm would could be told to rollback all transactions between two dates, but this seemed crazy. _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
