Fedora's package management tools -- including yum,pup, and pirut -- are all based on the RPM package format and management system. One little-known secret about RPM is that it can be configured to repackage files from an RPM package during package uninstallation, saving the (possibly modified) files into a new RPM package. The repackaged RPM incorporates any changes that you have made to the configuration files, scripts, and data files that were originally included with the software. This means that it's possible to rollback the uninstallation of software, which will restore the package to the state it was in before it was removed.
The rollback mechanism can also undo package installations by uninstalling the newly-installed packages, and since a software update is a performed by installing a new package version and then removing the old one, the rollback mechanism can also undo package updates.
Here's an example:
You install the package 'sendmail' when you install Fedora Core.
You modify the sendmail configuration to suit your needs.
You decide to remove sendmail using yum or pirut (or rpm, or yumex).
When sendmail is uninstalled (removed), the files from that package are gathered up -- including the modified sendmail configuration file -- and saved in a repackaged RPM package file.
You later decide that uninstalling sendmail was a bad decision. If you reinstall the original package file, the default configuration will be loaded. Instead, you can rollback the package removal, which causes the repackaged file to be installed -- including your modified configuration.
The repackage/rollback approach is far from perfect -- for example, data files created and used with a package (but not in files provided as part of the package) are not saved during repackaging, and some RPM scripts assume that packages are only upgraded and never downgraded. Nonetheless, package rollback can be a very useful feature, especially when an update breaks something that used to work.
Repackaging can take a lot of space, so it's disabled by default, and there is no way to enable it or to perform a rollback from the command line. Here, in a nutshell, are instructions for using this feature:
1. To configure yum (and pup, pirut, and yum-updatesd) to repackage RPMs, add the line tsflags=repackage to /etc/yum.conf. 2. To configure command-line rpm to do the same thing, add the line %_repackage_all_erasures 1 to /etc/rpm/macros. 3. Install, erase, and update packages to your heart's content, using pup,pirut,yumex,yum,rpm, and yum-updatesd. 4. If/when you want to rollback to a previous state, perform an rpm update with the --rollback option followed by a date/time specifier (the rollback is time-based because packages affect each other's configuration -- if you removed package a, then b, then c, and then rolled back only package a, the configuration could be broken). Some examples:
rpm -Uhv --rollback '9:00 am'
rpm -Uhv --rollback '4 hours ago'
rpm -Uhv --rollback 'december 25'
Repackaged files are stored in /var/spool/repackage.
This entry is based on an older post on http://blog.chris.tyers.info
Will this work for packages that I already have installed? For instance, I have Freshrpms's mPlayer installed. I then add the line tsflags=repackage to /etc/yum.conf. When I update, Livna's bad mplayer gets installed. Can I roll back to the Freshrpms version?
Yes, it should, because the repackaging will be performed at the time that Freshrpm's mplayer is removed (after you turned repackaging on). In other words, you can roll back to any time after you've enabled rollbacks, even if you're rolling back to a package that was installed before (and removed after) rollbacks were enabled.