On 10/2/06, John Runyan <johnrunyan1@xxxxxxxxx> wrote:
In my case, the %pre only does a pre-condition check. Nothing else. A single RPM is being installed. Do I still need the rollback procedure?
Can you guarantee that you will never have your rpm installed in a transaction that has 2 or more rpms? This guarantee can be made, in very tightly controlled environments where they are always installing transactions with 1 rpm (and in these environments you have choosen to handle dep sorting and various other things traditionally the domain of rpm). If you can make this guarantee then in this particular case your OK. In general, though I expect rpms to be installed in sets so that rpm can handle dependency closure and dependency sorting (i.e. I'm expecting it to typically be used in such a way that more resembles how it was intended to be used). Really, whether or not you want the %pre failures to cause a rollback is completely a local policy decision. But my instinct is that if your looking for transactional ACID like properties with upgrades, you probably want a simple upgrade successfully or completely rollback successfully. Cheers...james
--- James Olin Oden <james.oden@xxxxxxxxx> wrote: > On 10/2/06, John Runyan <johnrunyan1@xxxxxxxxx> > wrote: > > How do you stop RPM installation in the %pre > section? > > It shouldn't require the rollback procedure you > sent a > > link to, James, should it? > It absolutely does require that. The reason is > multi-faceted: > > - Pre-scripts can do things. They do not have > the same semanic as a solaris > verify script which is only used to check for > pre-conditions. > - Pre-scripts are not all ran at the begining of > the transaction, > but as each installed > package goes through the package state machine > (PSM) its > pre-scriplet is ran such > that the system has necessarily been changes by > the packages than > ran before it > in the transaction. > - scriptlets are opaque to RPM, so there is no > way to tell if a > script has changed the > system or not. > > When you stack these up you get that at the time of > a %pre scriptlet > failure the system could have been changed, > therefore the transaction > should be rolled back to bring the system back to > the original state. > Note, the therefore is based my environments rule of > rolling back > failed transactions. One could have alternate > policies. > > Also, another thing to consider that my article does > not discuss, is > that sometimes an "upgrade" of a system requires > multiple transactions > (at least if you are using the rpm cli). For > instance, you might > have one transaction with kernels and kernel modules > that were > installed, and then another with other packages that > were upgraded. > By the rules in my enviorment if a %pre failed in > the second > transaction, then you would want to roll back that > transaction and the > previous one. That is what the --arbgoal switch is > about (which is > not documented), which allow you to specify a roll > back goal to use in > the event of a failure. > > Cheers...james > > _______________________________________________ > Rpm-list mailing list > Rpm-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/rpm-list > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ 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
