[devel] [jbj на JBJ.ORG: rpm-4.0.3-ROLLBACKS test release]

[Dmitry V. Levin]

----- Forwarded message from Jeff Johnson <jbj на JBJ.ORG> -----

Date: Mon, 23 Apr 2001 17:56:01 -0400
From: Jeff Johnson <jbj на JBJ.ORG>
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.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Тип     : application/pgp-signature
Размер  : 232 байтов
Описание: =?iso-8859-1?q?=CF=D4=D3=D5=D4=D3=D4=D7=D5=C5=D4?=
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20010424/d81a9999/attachment-0001.bin>