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.
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
