James Olin Oden (joden@xxxxxxxxxxxxxxxxxxxxx) wrote: > 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. [snipped] > All this said, does this seem to be a sane path, or the right thing to > do? Is there a better way? I talked to Jeff Johnson about this in April last year and he said: > I've thought about running all %pre's as single concatenated script, > installing all payloads as temp files, and then incrementally > committing or aborting file changes based on %post success in order > to provide a stronger apply/commit database transaction for > packages. > > More trouble than its worth, changing rpm these days is non-trivial. Running all %pres first feels more like the Right Thing To Do than any auto-rollback because it's preventative rather than retroactive, but I'm not sure how it could handle `Requires(pre): foo', since `foo' would need to be installed fully before the %pre could run. I'm not sure I understand where Jeff was going with his suggestion of actions being based on the result of %post success however. I had always envisaged the semantics of %post being "try to finish up cleanly by running %post, but if it fails, we consider it an unfortunate partial success rather than a failure which then gets rolled back". If %post succeeding is to be considered a strict requirement for success, then rpm should be more diligent about cleaning up from its failure. _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
