[Rpm-devel] RPM transactions
James.Oden at tekelec.com
Fri Jan 20 10:09:41 EST 2006
> I just wanted to understand how RPM figures out the success or failure
> of its transactions.
> Say you have package "a" which depends on package "b".
> Say in package b's pre-installation script you define a command which
> won't succeed. So overall your pre-installation script of package "b"
> will fail during installation. Which means package "b" won't install.
> Now, when you do `rpm -Uvh a.rpm b.rpm`, a will install because its
> dependency is satisfied but b won't because its pre-installation
> exit status would be false.
> Does RPM plan to take care of this issue ? If not, is it because it is
> fundamentally not doable ?
> IMO, this is an important feature to tackle.
The real issue (not to take away from anything Jeff said as its all good
and to the point) that you are seeing is that RPM as a default policy
delivers packages in a transaction using best effort strategy. This
means that if package A fails to install, it will still try to install
package B. That said if A was an upgrade it will try to snip the
corresponding erase element (otherwise you might end up with no
There is an alternate policy in the latest version of RPM, called
autorollback, which attempts to rollback a transaction at the point a
package fails to install or erase properly. The rollback itself is best
effort (which seems reasonable to me...wouldn't want to rollback the
What is missing, I believe, is a third policy of stopping on a failed
package. Rollbacks, though becoming better and actually having been
deployed in production networks, are not for the faint of heart. They
require absolutely perfect configuration management. So a full stop
policy being supported is IMHO a good thing and would meet the criteria
you are looking for, unless you really want the thing to be rolled back
automatically (if so this exists).
More information about the Rpm-devel