Yum rollback and repackage
Introduction –
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.
Open /etc/yum.conf file and put below two line
#yum rollback select enable
tsflags=repackage
or append it a simple way 🙂
[root@testbed ~]# echo “tsflags=repackage” >> /etc/yum.conf
Now create or edit /etc/rpm/macros and put “%_repackage_all_erasures 1” entry in it.
[root@testbed ~]# echo “%_repackage_all_erasures 1” >> /etc/rpm/macros
[root@testbed ~]# cat /etc/rpm/macros
%_repackage_all_erasures 1
Repackaged files are stored in /var/spool/repackage
[root@testbed ~]# ll -ld /var/spool/repackage
drwxr-xr-x 2 root root 4096 Sep 4 2009 /var/spool/repackage
Now we are test it with python packages, (I have used centos 5.5 for it)
[root@testbed ~]# yum -y install python*
Installed:
python-dmidecode.i386 0:3.10.13-1.el5_5.1 python-docs.noarch 0:2.4.3-1.1 python-exo.i386 0:0.3.4-1.el5.centos
python-imaging.i386 0:1.1.5-5.el5 python-imaging-devel.i386 0:1.1.5-5.el5 python-lcms.i386 0:1.18-0.1.beta1.el5_3.2
python-pyblock.i386 0:0.26-4.el5 python-setuptools.noarch 0:0.6c5-2.el5 python-tools.i386 0:2.4.3-27.el5_5.3
Dependency Installed:
exo.i386 0:0.3.4-1.el5.centos libbdevid-python.i386 0:5.1.19.6-61.el5_5.2 libxfce4mcs.i386 0:4.4.2-1.el5.centos
libxfce4util.i386 0:4.4.2-1.el5.centos libxfcegui4.i386 0:4.4.2-1.el5.centos tix.i386 1:8.4.0-11.fc6
tkinter.i386 0:2.4.3-27.el5_5.3
Updated:
python.i386 0:2.4.3-27.el5_5.3 python-devel.i386 0:2.4.3-27.el5_5.3 python-virtinst.noarch 0:0.400.3-9.el5_5.1
Dependency Updated:
mkinitrd.i386 0:5.1.19.6-61.el5_5.2 nash.i386 0:5.1.19.6-61.el5_5.2
Complete!
[root@testbed ~]# ls /var/spool/repackage/
mkinitrd-5.1.19.6-61.i386.rpm python-2.4.3-27.el5.i386.rpm python-virtinst-0.400.3-9.el5.noarch.rpm
nash-5.1.19.6-61.i386.rpm python-devel-2.4.3-27.el5.i386.rpm
Yum Roll Back options available:
* rpm -Uhv –rollback ‘9:00 am’
* rpm -Uhv –rollback ‘4 hours ago’
* rpm -Uhv –rollback ‘december 25’
[root@testbed ~]# date
Mon Jan 24 12:10:19 IST 2011
Now we reverting package rollback to a previous state.
[root@testbed ~]# rpm -Uhv –rollback ‘9:00 am’
Rollback packages (+5/-21) to Mon Jan 24 11:58:17 2011 (0x4d3d1c01):
Preparing… ########################################### [100%]
1:nash ########################################### [ 10%]
2:python ########################################### [ 20%]
3:mkinitrd ########################################### [ 30%]
4:python-devel ########################################### [ 40%]
5:python-virtinst ########################################### [ 50%]
Cleaning up repackaged packages:
Removing /var/spool/repackage/mkinitrd-5.1.19.6-61.i386.rpm:
Removing /var/spool/repackage/nash-5.1.19.6-61.i386.rpm:
Removing /var/spool/repackage/python-2.4.3-27.el5.i386.rpm:
Removing /var/spool/repackage/python-devel-2.4.3-27.el5.i386.rpm:
Removing /var/spool/repackage/python-virtinst-0.400.3-9.el5.noarch.rpm:
Now you can check your previous versions of python & mkinitrd, nash packages.
[root@testbed ~]# rpm -qa|grep -E ‘python|mkinitrd|nash’
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:
Ref: http://dailypackage.fedorabook.com/index.php?/archives/17-Wednesday-Why-Repackaging-and-Rollbacks.html
-Ravi