50 lines
3.0 KiB
Plaintext
50 lines
3.0 KiB
Plaintext
The term "transaction rollback" is jargon for a method of maintaining
|
|
sets of packages that are applied to boxen sequentially. In a nutshell,
|
|
packages that are to be installed/removed are aggregated into something
|
|
called a "transaction set". Each transaction set is then assigned a unique
|
|
identifier so that the packages in the set can be distinguished, Finally,
|
|
since the transaction set identifier (TID) can be ordered, transaction sets
|
|
can be managed just like packages, since each TID will identify the sets
|
|
of packages to be installed/removed at each stage in a software life
|
|
maintenance cycle. The approach is very similar to what rpm already does
|
|
when encapsulating sets of files in packages which are then ordered
|
|
according to the package epoch, version and release.
|
|
|
|
The current release of rpm (rpm-4.0.2) has added TID's to every package
|
|
installed. In addition, an image of the header is preserved in the rpm
|
|
database that is identical to what was in the original package file.
|
|
This permits rpm to reconstruct the original package from the installed
|
|
components at any time.
|
|
|
|
The next version of rpm (rpm-4.0.3, now in a release cycle now) has added the
|
|
ability to repackage all the components to construct a copy of the original
|
|
package as part of a software upgrade. The reconstituted package as well
|
|
as the newly installed packages in the transaction set are all marked with
|
|
a TID that identifies the software upgrade uniquely. Thus software
|
|
replaced on a boxen is repackaged, and the packages can be archived
|
|
(or otherwise saved) as part of normal software management.
|
|
|
|
What remains to be done is to use the ordering property of TID's so that
|
|
transactions can be "rolled back" to any point in the past for which
|
|
the old packages are available. This will require a B-tree database
|
|
index for the currently installed transaction sets, and saving the names
|
|
of the packages that were removed. For the commonest case, a software
|
|
upgrade, each installed package can carry the names of replaced
|
|
(and repackaged) packages that were performed as a side effect of the
|
|
package upgrade. Other means will be needed to keep track of transaction
|
|
sets that only removed packages, however. Finally, a "transaction rollback"
|
|
loop still needs to be written that will walk backwards through the ordered
|
|
TID's, reconstructing the transaction set but reversing what packages
|
|
are removed and/or installed.
|
|
|
|
In addition to "transaction rollbacks", rpm will soon have the ability
|
|
to apply/commit/undo software transactions atomically. The next version of
|
|
rpm (rpm-4.0.3) already has the ability to apply/commit/undo file changes.
|
|
The term "apply" means that the file is installed with a temporary name
|
|
(currently just the original file name with the TID appended), "commit"
|
|
is the operation of renaming the file and setting it's mode and ownership,
|
|
while an "undo" is just a removal of the temporary file. The concepts
|
|
of apply/commit/undo are being extended to packages as a set of
|
|
file operations, and will need to be extended yet further to transaction
|
|
sets as well.
|