Re: Autorollback patch question...

[Adam Spiers <adam spiers net>]

James Olin Oden (joden@malachi.lee.k12.nc.us) 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.