----- Forwarded message from Jeff Johnson ----- Date: Mon, 23 Apr 2001 17:56:01 -0400 From: Jeff Johnson To: rpm-list@redhat.com Subject: rpm-4.0.3-ROLLBACKS test release Mail-Followup-To: rpm-list@redhat.com X-Mailer: Mutt 0.95.4us Reply-To: rpm-list@redhat.com As promised: > Almost all of the code from transaction.c down to cpio.c has been rewritten. > I will put test packages on ftp.rpm.org as soon as I can figger what is > likely to be in the next version of rpm. I've put up a test release for the "next version" of rpm at ftp://ftp.rpm.org/pub/rpm/test-4.0.3-ROLLBACKS This build still has db1 support, but db1 support is gonna be dropped right after I finish internalizing a copy of db-3.2.9 within the rpm source tree. A long overdue soname version change will happen soon thereafter, like, this week. Be forewarned: This is development code, I dunno if it works at all. That being said, I've been using this code w/o problem for nearly 2 months. Then again, I do this for a living. Caveat emptor. Final release of rpm-4.0.3 is probably 4-10 weeks from now, but the changes are large enough that I want to make a copy available soonest. Below is a very preliminary gloss on what "transaction rollbacks" are. The text is also in /usr/share/doc/rpm-4.0.3. Please submit bug reports, RFE's, patches, etc as always at http://bugzilla.redhat.com 73 de Jeff ============================================================================= 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) 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. -- Jeff Johnson ARS N3NPQ jbj@jbj.org (jbj@redhat.com) Chapel Hill, NC _______________________________________________ Rpm-list mailing list Rpm-list@redhat.com https://listman.redhat.com/mailman/listinfo/rpm-list ----- End forwarded message ----- Regards, Dmitry +-------------------------------------------------------------------------+ Dmitry V. Levin mailto://ldv@alt-linux.org ALT Linux Team http://www.altlinux.ru/ Fandra Project http://www.fandra.org/ +-------------------------------------------------------------------------+ UNIX is user friendly. It's just very selective about who its friends are.