[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Rolling back a failed transaction...

I think that its important to note that not all failures are treated as
such; the post-install/post-uninstall scriptlet failures for example _will_
cause rpmtsRun() to return error _but_ will apear in the database
as if all went well. (i.e. a failure to install usualy results in there being
no entry in the db and vice-versa). I'm not about to look it up in the
code but I remember there was some inconsistancy in that area.

   I've been on this list a short 6 to 8 months and I've seen all kinds
of good ideas like this pass by. I dont see anything getting done.
I dont see anyone communicating and actively deciding what
should be the future of rpm. It's kinda sad because I would willingly
throw in some hours. After working so closely with it I've developed
a likeing to this project.

> that I think I could implement, but I want to make sure that it would
> be acceptable to the RPM developers.

My feelings exactly.

I hope I haven't offended anyone with my slight frustration on this
particular topic. I do not mean for this to go "up-in-flames".

Cheers all,

If, you recieve this email with all kinds of different fonts and wierdness
I would sincerely like to apologize ;-) Just installed RH9 and I haven't
configured a thing, I havent even compiled enlightenment yet.

James Olin Oden wrote:

Its been discussed before how if a transaction element fails to install
the transaction is presently not stopped. In many situations this is the
correct behaviour, but not in all. I have been studying the rpm code
to determine what might be a suitable way of allowing for rpm to instead
of trudging forward when a transactioin element fails to install to actually have it instead rollback the transaction. I have a strategy
that I think I could implement, but I want to make sure that it would
be acceptable to the RPM developers. Here is the strategy in a nutshell:

1) The rollback would be triggered by some macro,
say _rollback_transaction_on_failure being set to one.
This would make it not the default behavior.
2) As rpmtsRun was going through each transaction element
and running through the package state machine, I would
build a transaction which makes install elements
erase elements and erase elements install elements (well
actually there repackaged packages).
3) If the psm returns with an error I would run this other transaction I built to undo what had just occured.

Would this be an acceptable strategy?  Am I missing something?
Thanks for any and all comments...james

_______________________________________________ Rpm-list mailing list Rpm-list@redhat.com https://www.redhat.com/mailman/listinfo/rpm-list

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []