Up2date --undo "This feature is deprecated and no longer functional."

Question

We are trying to se up a Patch Mangement strategy. Our initial thoughts are to have a yum repository updated to a point in time. Then this repository will be used to update the test environment first, then (once it is tested) the dev environment, then production. All from the same 'static' yum repository.
Our question comes in about 'rolling back' this upgrade if something breaks. The up2date --undo is not longer functional. We have read alot about the rpm rollback and repackage features. But cannot find any current documentation.
Is anyone managing their patching this way, and have a 'rollback' function in place?
Thanks.

Answer 1

While the "--rollback" feature appears to be still present in the versions of rpm(8) shipped with RHEL5/OEL5, the feature was eventually discarded as being unreliable. The RPM/YUM folk decided this was the wrong approach anyway so the rollback code just got tossed.
Here is a snippet from the Fedora 11 rpm(8) changelog. Now ordinarily you can see the changes in an RPM package like this:
$ rpm -q --changelog <rpm-package-name>But the RPM changelog has gotten so long, some of it is just packaged in the stock documentation:
$ cd /usr/share/doc/rpm-*/
$ bzless Changelog.bz2
commit d9c780d19edeaf81427411205a9620c9516902c1
Author: Panu Matilainen <[email protected]>
Date:   Mon Mar 17 14:36:43 2008 +0200
    Remove rollback and repackage from documentation
commit db37b74a2bfebf067f421b891d3837baaca7fc6f
Author: Panu Matilainen <[email protected]>
Date:   Mon Mar 17 14:27:03 2008 +0200
    Nuke leftover rollback test program, update translations
commit d89482a7c7777d379ab415ebba747b6af19babdb
Author: Panu Matilainen <[email protected]>
Date:   Mon Mar 17 14:10:11 2008 +0200
    Remove repackage support to finish off with rollback
    The two main classes of rollback/repackage need are
    1) Gimme back the previous version, this broke XYZ on my system.
       This is better handled by downgrading to the previous version of original
       package instead of repackaged garbage. We should maintain real package
       (version) history somewhere.
    2) Upgrade messed up my configuration.
       Instead of repackaging everything we could be far more intelligent
       wrt config files, stick them into real version control or at least have
       hooks to do so.
    RPMCALLBACK_REPACKAGE_* and RPMTRANS_FLAG_REPACKAGE definitions left around
    to avoid needlessly breaking everybodys callbacks (for now)
commit 37543ee0405c38a9d54a12bf0d54698773a3933c
Author: Panu Matilainen <[email protected]>
Date:   Mon Mar 17 11:53:27 2008 +0200
    Remove rollback support
    - not possible to do reliably within rpm
    - effort is better wasted on investigating fs-level snapshots, which
      is way beyond rpm scope except for hooks to interact with the snapshot
      mechanism to communicate beginning/end of transaction and such
commit ed78cef2c3e14df29d95b476f00d51203fbe098e
Author: Panu Matilainen <[email protected]>
Date:   Mon Mar 17 12:04:39 2008 +0200
    Remove support for automatic rollback on failure
    - doing this reliably from rpm is simply not possible as there's no way
      to undo script actions, might as well not pretend we can
    - for a feature that's not generally usable it complicates mainline code
      way too much
...With that in mind, I would seek another solution such as adequate full back-up archives :D