descriptions of some rollback "scenarios" and what we
considered acceptable things to do.


General questions:
	do we require all rpm actions to be
	with rollbacks once we "turn it on"?

	do we allow rollback a transaction if
	something has been done non-rollback
	since that transaction?

	If we allow mixing rollback and non-rollback
	transactions, how do we determine if a failed
	rollback is due to our error, or non-rollback
	induced state inconsistincies.

Decided Policies:
	A package can only be rollbacked once (ie,
a given repackaged rpm can only be installed once,
then it's deleted). If that package is updated again,
the now installed package will be repackaged.

case 1:
rm foobar-2.0-1 with rollbacks, install foobar-1.0-1
without rollbacks. The transaction looks like:

install time: Fri Nov  8 12:28:18 2002   tid:1036776498
                [-] foobar-2.0-1:

Since foobar-1.0 is installed, running the transaction
wants to "i"nstall foobar-2.0-1, but that doesnt work
since foobar-1.0-1 is installed. Should up2date "U"pgrade
in this case?  all cases? all cases but kernel? only
in cases where another version of that package is installed
except for kernel?


case 2:
installed a new kernel with rollbacks. At some point,
someone removes all other kernels (lets say, with rollbacks,
doesnt matter). 

transaction looks like:

install time: Fri Nov  8 12:18:09 2002   tid:1036775889
		[-] kernel-2.0-1
                [+] kernel-3.0-1

Do we allow the user to roll this back (aka, deleting
the only kernel installed). Do we blacklist pure
erasures of kernels? rpm? up2date? glibc? everything
in base?


case 3: 
just like case 1, except instead of the transaction
being a newer package, it is an older package. 


case 4:
ditto case 1, except transaction has the _same_* package
* keeping in mind "same" means same n-v-r-e, but the 
contents of the repackage rpm could infact be different
(think modified config files) 
Rule: if this happens, we "--force" the package to
install



case 5:
(similar to case 4)
rpm -Uvh --force package foo-1.0-0 with repackage
transaction looks like:

install time: Fri Nov  8 12:18:09 2002   tid:1036775889
                [-] foo-1.0-1
* same caveats as case 4

Rule: if this happens, we "--force" the package to
install

