On Mon, 26 Jan 2004, Adam Spiers wrote: > James Olin Oden (joden@xxxxxxxxxxxxxxxxxxxxx) 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/rpm-list > _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
