Feature idea: checkpoints/rollback

[Cliff Wells]

On Fri, 2009-09-18 at 12:59 -0400, Jeff Johnson wrote:
> On Sep 18, 2009, at 12:51 PM, Cliff Wells wrote:
> 
> > This isn't a new idea, but I don't know if it's been discussed here
> > before.
> >
> > It'd be useful if Smart could have a couple of facilities for doing
> > rollbacks of upgrades.   I'm thinking of two mechanisms:
> >
> > 1) Checkpoints.  When a package is to be upgraded/removed, save a copy
> > of the package (and any dependencies) that will be changed, along with
> > some metadata that describes the checkpoint.   I wouldn't suggest  
> > doing
> > this on every update, just if the user specifies it.
> >
> > 2) Auto-checkpointing of specified packages.   I've been using  
> > Chromium
> > lately (it rocks) and every now and again, they ship a broken version.
> > It'd be nice to be able to specify that some particular package should
> > never be altered without a checkpoint so that it can be rolled back  
> > to a
> > previous version.
> >
> 
> All of the above has been attempted. RPM had (if you use @rpm.org) and
> has (if you use @rpm5.org) a --repackage mechanism to save what
> used to be there when upgrading.
> 
> The issues are more complex because of different package managers and
> distros, its impossible to get consensus on a checkpoint/rollback  
> mechanism.

You know, a simpler but still useful option would be to simply keep
older copies of the package around.   For instance, I was able to solve
my Chromium issue because Smart presented me with both the most recent
version as well as one previous version.   I assume this is because the
older version still happened to be available in the repo or in my local
cache.

If there were a mechanism to specify what and how long to hold onto
cached packages, it might be "good enough", since the natural dependency
resolution would get you pretty close to where you were before.

Regards,
Cliff