Re: Autorollback patch question...

[James Olin Oden <joden malachi lee k12 nc us>]

On Mon, 26 Jan 2004, Adam Spiers wrote:

> James Olin Oden (joden@malachi.lee.k12.nc.us) wrote:
> [snipped again]
> 
> > 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 agree that as many preventive measures should be taken as possible 
(within the bounds of sanity), because if you can prevent a system from
getting to a botched state before it happens that is the right thing to 
do.  Where I believe I diverge from your POV is that I also believe that
no matter how much testing you do, your going to miss something (whether
the testing involve testing your packages in chroot environment, or 
pre-testing before running an rpm transaction).  Realizing this reality,
being able to automatically undo a failed rpm transaction is a good thing.
In the space I work (the telcom space), one way or another I would have 
to clean up the mess, and patching rpm such that it automatically undoes 
a failed transaction seemed (still seems) a valid aproach to the problem.

As an aside, having %pre's concatenated won't work in an install, and 
would break "Requires(pre):: foo" as you alluded to.

> 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". 
Note, this is ultimately a policy decision.   Where I work, its a 
completely failure and we want the system back the way it was before the
transaction occured (i.e. we think of an rpm/package transaction as a 
transaction, not just a set of packages we would like to see applied to 
the system), in other places a best effort stratagy of delivering rpms 
once the transaction starts rolling would be the preferred policy.  
Actually, this is one of the reasons that I made the mechansim of 
autorollbacks dependent on a macro being set to request its use as
a policy decision.

> If %post succeeding is to be considered a strict
> requirement for success, then rpm should be more diligent about
> cleaning up from its failure.
>
Again, I think this is a policy decision, and all I really want is the
mechansim (rpm) to support such a policy (i.e. treating a failure in
%post as a hard failure).

Cheers...james

P.S.  Would have responded earlier but our mail server was down when
your email was sent.  Thanks for the reply though.
 
> 
> _______________________________________________
> Rpm-list mailing list
> Rpm-list@redhat.com
> https://www.redhat.com/mailman/listinfo/rpm-list
>