Conary:conary rollback

From rPath Wiki

Conary's rollback system works like a push-pop stack in which rollbacks are "pushed" onto the stack when changesets are applied and "popped" off the stack when a rollback command is issued. If you wish to restore to a system configuration from a previous time, identify the rollback representing that desired point in time (using conary rblist), and "pop" the stack to that level by repeatedly applying the most recent rollback (using conary rollback]]).

Use conary rollback to roll back to a previous updated state of your Conary-based system.

In this example, rollback r.686, the most recent rollback, consisted of the update of the package zile to a new version, and the user needs to roll back to the previously installed version of zile.

# conary q zile
zile=2.2.18-1-1

# conary rollback r.686
Applying update job 1 of 2:
    Update  zile(:data :doc :runtime) (2.2.18-1-1 -> 2.2.16-1-1)
Applying update job 2 of 2:
    Update  zile(:data :doc :runtime) (/contrib.rpath.org@rpl:devel/2.2.16-1-1 -> /contrib.rpath.org@rpl:devel//local@local:LOCAL/2.2.16-1-1)

# conary q zile
zile=2.2.16-1-1

A conary query on zile shows the version was rolled back to 2.2.16-1-1.

Although the stack-like behavior of Conary's rollback system provides a sequential process for undoing complex changes, it cannot be used to undo changes out of sequence. For example, suppose there is a single trove A that is erased in an update and another trove B erased in a subsequent update. You discover the need to undo the change made to trove A. However, you cannot undo the change to trove A without first undoing the subsequent change to trove B. This situation can typically be address by updating trove A to its prior version.

One possible use of conary rollback is to reverse a series of changes in which a particular single change cannot be identified as the reason a particular issue appeared. For instance, installing a kernel and subsequently installing two software upgrades designed to work with the new kernel results in three rollbacks. To return to using the previous kernel, identify the rollback that included the kernel upgrade and use conary rollback on that rollback to reverse all the subsequent actions, ensuring the software on the system goes back to being usable with the previous kernel.

An alternative to specifying a particular rollback number is to designate the number of steps to roll back. In the kernel example previously mentioned, conary rollback 3 would apply three rollbacks, including the two software updates and the kernel installation.

Do not roll back to a specific point unless you are sure that all included rollbacks can be removed without adverse effects on the system.