When packages depend on other packages, you may have to install multiple packages to add a single application. Some of the packages may install cleanly; others may not. But you have to install all of the packages to get the complete application. The designers of the RPM system understood this problem and added the concept of transactions to RPM.
This chapter covers transactions and how they can help you cleanly install a set of dependent packages. But transactions won’t solve all your problems. You still have to resolve conflicts and dependencies by using the techniques provided in the last three chapters.
6.1. Understanding Transactions
A transaction is a way to delimit a set of operations. All the operations can be undone, often called rolled back. Once rolled back, the system is back in the same state it was prior to the transaction. If all the operations succeed, though, the system will be in a new state. The key issue is that all of the operations must complete successfully, or you can roll back the entire transaction. The assumption is that if any of the operations fail, the system will be in an inconsistent or erroneous state. Transactions are a way to prevent that.
Transactions are common when working with databases, but they are just as important when working with packages.
Starting with RPM version 4.0.4, transactions and rollbacks became a workable part of any administrator's toolkit. With RPM, the rpm command sets up a transaction any time you attempt to install, remove, or upgrade more than one package. The rpm command automatically makes a transaction.
6.1.1. When do you need transactions?
Whenever you install or remove packages, the RPM system assigns a transaction and a transaction ID to the set of packages. You can then perform operations on the packages that share the same ID, including rolling back the transaction.
Note
Rollbacks work only for package upgrades with the 4.1 version of the RPM system, not package installs
The RPM system saves an image of the RPM package header for each package installed or removed. You can use this image, along with RPM transaction IDs, to back out of transactions should something go wrong when setting up your system.
The main advantage of transactions with RPM, though, is the fact that the rpm command automatically sets up a transaction for all the packages on each command line and does not perform the operation if any package fails. This ability to automatically set up transactions for each call to the rpm command eliminates many errors when working with packages.
Use a transaction when you need to be sure that a set of packages install properly.
6.1.2. Backing out of transactions
With RPM, backing out of a transaction involves two operations: rolling back the transaction and reinstalling the former packages to restore the previous system state. In the simplest case, the rpm command handles all the tasks for you. If you try to install, upgrade, or remove multiple packages and any package fails, the rpm command will restore the system state for you.
This automatic support for transactions is a great help to system administrators, but it only applies when you first install, upgrade, or remove the packages. If you have upgraded your system and later discover problems, then you can also use the --rollback option to roll the system back from a set of upgrades, in a limited set of circumstances.
