Re: rpm rollback features...

[Jeff Johnson <jbj redhat com>]

On Mon, Jul 15, 2002 at 09:12:56AM -0500, James Olin Oden wrote:
> Thanks for your lengthy reply Jeff.  That really distilled some
> things for me.  At least now I think I understand (-;
> 
> After some intial testing I came up with one problem.  Here is the
> scenario:
> 
> 	At time T1 RPM X is not installed.
> 	At time T2 RPM X Version V1 Release R1 is installed.
> 	At time T3 RPM X Version V1 Release R2 is installed.
> 	At time T4 a request to rollback to  T3 > t > T2 is made.
> 	At time T5 a request to rollback to  T2 > t > T1 is made.
> 
> Note all times ordered (Ta < Ta+1).  Anyway it appears that the 
> first rollback works fine, but the second one which would equate to
> a removal of the application does not work fine as it does nothing.
> That is the rollback to T2 > t > T1, the time when the rpm was not
> installed leaves the rpm installed.  
> 
> I distilled this further to the following scenario:
> 
> 	At time T1 RPM X is not installed.
> 	At time T2 RPM X Version V1 Release R1 is installed.
> 	At time T3 a request to rollback to  T2 > t > T1 is made.
> 
> In this scenario I am simply trying to roll back the initial install
> of an rpm, so I am not doing multiple rollbacks.  The result is the same.
> 

Yup. The current implementation will only rollback upgrades, not installs,
to avoid the problem of accidentally cleaning your disk by typing

	rpm -Uvh --rollback "20 years ago"

I'll be happy to show you how to eliminate the safety check if/when the
time comes.

> Now one might consider that if the rollback to when the rpm was not
> installed would open the door for disk scrub.  I don't think this is the
> case if in tracking TIDs, one makes a special rule for RPMS that part of
> the first TID of the system that they cannot be removed.  
> 
> Implentation details aside the real world scenario that I am trying to 
> deal with is:
> 
> 	A system is in the field with a certain set of RPM's installed.
> 	A upgrade to the system occurs, and x number of new RPM's are
> 		added.
> 	For whatever reason the upgrade is not considered a good thing
> 		and a rollback/backout must occur.
> 
> In this scenario, the new rpms need to be removed.  Now this can be 
> handled external from RPM, but things are simplified on my end if 
> RPM handles this.
> 
> If after reading this you consider this to be a bug, I will submit a 
> bugzilla report, but I wanted to get some concensus on what the best
> approach is.

What's needed is more precise vocabulary for "upgrade". For rpm rollback
purposes, "upgrade" means that there exists a package with the old bits
contained therein, after the upgrade, not the case when a new package is
first installed.

HTH

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC