Fedora Linux

tsflags=repackage
# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d

The tsflags line may appear anywhere after the [main] tag.

Once you have set this up, any package removal or upgrade (which is actually an installation and a removal performed together) will create a backup of the old data.

You can then roll back to a particular point in time by performing an upgrade with rpm and specifying the --rollback option with the time you wish to revert to:

# rpm -Uhv --rollback '10 minutes ago'
Rollback packages (+1/-0) to Sat Oct 29 15:23:40 2005 (0x4363cc3c):
Preparing... ########################################### [100%]
1:abe ########################################### [ 50%]
Cleaning up repackaged packages:
Removing /var/spool/repackage/abe-1.0-5.i386.rpm:

Notice that the rollback installed one package and removed no packages (+1/-0) , and that the rollback data was deleted after the rollback.

The format for --rollback values is quite flexible; most reasonable dates and times are interpreted correctly. Here are some examples:

# rpm -Uhv --rollback 'last Monday'
# rpm -Uhv --rollback '2 hours ago'
# rpm -Uhv --rollback '10 Jan 2007 16:30'
# rpm -Uhv --rollback 'march 17'
# rpm -Uhv --rollback '9:00 am'
# rpm -Uhv --rollback '4:30 pm last Monday'
# rpm -Uhv --rollback 'yesterday'

5.4.2. How Does It Work?

When repackaging is enabled and RPM package updates or removals are performed, the metadata for the package to be removed is combined with the current state of the package's files to create a new RPM package. This is different from the original package used to install the software because it reflects any changes that were made to the package's files. Configuration changes, deleted files, high scores, changes in sample data, and script modifications are all included in the repackaged file. This permits the package to be restored in exactly the same form as it was when it was removed.

However, files that were not in the archive portion of the original RPM package are neither repackaged nor erasedso if you install a package such as MySQL and create files with it (databases, in the case of MySQL), those files will not be removed when MySQL is removed, and they won't be restored if the package removal is rolled back.

Repackaged files are in standard RPM format, with two exceptions: the transaction ID (date and time of the transaction in seconds since the start of 1970) is recorded in the RPM, and the signatures and hashes are usually invalid because the repackaged files are different from the original files (at least the modification time of the files has changed, and in many cases the contents of one or more files, as well).

5.4.3. What About...

5.4.3.1. ...rolling back a package installation?

Installing a package does not create a repackaged RPM because there are no files already on the system that need to be repackaged. However, the package installation is recorded in the RPM database, and that is enough information for rpm to roll back the transaction: it just erases the package.

5.4.3.2. ...rolling back a rollback?

Sorry, there are just too many variables to roll back a rollback! To prevent confusion rpm deletes repackaged files once they have been used for rollback.

5.4.3.3. ...seeing what will happen during a rollback, before I decide to do it?

rpm 's --test option is very useful for this:

# rpm -Uhv --test --rollback '1 minute ago'
Rollback packages (+1/-0) to Sat Oct 29 22:47:27 2005 (0x4364343f):
Preparing... ########################################### [100%]
Cleaning up repackaged packages:
Removing /var/spool/repackage/abe-1.0-5.i386.rpm:

From the output, you can see that this rollback will result in one package being reinstalled and no packages being removed ( +1/-0 ). The package being reinstalled can be identified from the clean-up line: it's abe .

To proceed with the rollback, execute the command again without the --test option:

# rpm -Uhv --rollback '1 minute ago'

5.4.3.4. ...the disk space used by the rollback files?