Re: Rollback

[James Olin Oden <joden lee k12 nc us>]

On Fri, 6 Aug 2004, Chad Kimmerle wrote:

> So James, the current version of RPM in Redhat Enterprise Desktop and
> Fedora Core 2, do they also have the RPM rollback bug that goes through
> with installs even if there is a problem?
>  
> I was trying to figure out how to use the rollback feature.  According
> to the author of Red Hat RPM guide, the --repackage switch on the RPM
> command makes repackage .RPMs in the /Var/spool/repackage directory. 
> That way, he says, you can use the RPMBUILD command to turn them back
> into regular RPMs.  But he does not tell the readers how to do that.  
>
First off everything this author says about --repackage and rpm 
transactions is completely wrong (or misleading at best at times).
I keep meaning to write the guy but I have been completely swamped
for the longest time.  If you ignore stuff about --repackage and 
transactions his book is fine.
  
> Do you know how to use the RPMBUILD command to turn repackages into
> regular rpms?
>
There is a program out there that does this, but frankly that was never 
the intent of --repackage (BTW, have you read my article in the linux 
journal, I explain all this [without disparaging remarkes towards the rpm
book of course (-;]).
  
> What does the rollback feature have to do with the repackaging?
>
Everything.  Here is a short example:

	#
	# Get time before transaction
	T1=$(date '+%d/%m/%Y %H:%M:%S')
	rpm -Uvh --repackage foo-1-1.i386.rpm  

	#
	# Since the TID of the transaction is seconds since
	# epoch wait at least a second before rollback
	sleep 2		# And I am paranoid (-;

	#
	# Now rollback transaction
	rpm -Uvh --rollback "${T1}"

So the first rpm -Uvh with --repackage will upgrade or install
foo, and if it is an upgrade will repackage the old version before
upgrading.  The second rpm -Uvh with --rollback will rollback all
transactions from now to the rollback goal ($T1 in this case).
If that first transaction was an upgrade then it will re-install 
the repackage package that was created before upgrading foo.  If it
was an install and the proper macro has been set (%_unsafe_rollbacks)
then it will erase foo.

Note, my example is transaction with 1 element, and in my example I
am only rolling back one transaction, but rpm --rollback will 
rollback as many transactions as occured up until the rollback goal
and each of these transactions can have N elements.   It is required
that all transactions that are rolled back were ran with --repackage
otherwise everthing will look like an initial install (which translates
to an erase on the rollback...very bad!).  So its best to do the following
in your /etc/rpm/macros file:

	#
	# Set this to the time before which you do not want 
	# packages to be erased in a rollback.  It is in 
	# seconds since epoch.  It should generally be set to the time
	# after the system was initial installed, or you can reset it
	# after you have decided to "commit" a various set of 
	# transactions.  Unfortunately, there is no don't do any rollbacks
	# past this date macro (yet (-;).
	%_unsafe_rollbacks          10000000

	#
	# If non-zero, all erasures will be automagically repackaged.
	# We want all erasures to be repackaged.
	%_repackage_all_erasures    1

That last one is the most important one, as it means you don't have to 
trust your sysadmins to throw --repackage on the command line.

Note there is no mechanism with rpm to clean up the repackage directory,
but if you ask I have a script (you'll want to adjust it for your needs)
that provides this functionality).

Cheers...james

P.S. I forwarded this to the rpm list at redhat just in case anyone
else has a similar question.