Re: rpm rollback features...

[James Olin Oden <joden lee k12 nc us>]

> 
> > > 
> > > Yup. The current implementation will only rollback upgrades, not installs,
> > > to avoid the problem of accidentally cleaning your disk by typing
> > > 
> > > 	rpm -Uvh --rollback "20 years ago"
> > > 
> > > I'll be happy to show you how to eliminate the safety check if/when the
> > > time comes.
> > >
> > Actually, I want the saftey check but with an exception.  I want rpm 
> > at "system installation" to mark the set of RPM's that were installed then
> > to be part of the original system install.  RPM can know that it is 
> > system install, because no RPM's have been added to its database yet 
> > (or this is how I understand things?).  Ever there after, any "rpm install" 
> > is known to be part of a "system upgrade" as it was not part of the
> > "system install".  So when a rollback is requested to a time before
> > a particular package did not exist on that system, if the package was
> > not part of the "system install", and thus part of the "system upgrade" 
> > the package can now be removed.    If on the other hand the package
> > was part of the "system install" it would not be removed.
> > 
> 
> OK. Since every package has an install transaction ID (TID, read: time stamp),
> you would like to see a safety check that prevents any package with
> the earliest existing transaction ID from being erased with --rollback. FWIW,
> finding the earliest TID and preventing a rollback iff all the elements
> in the transaction have the earliest (or more generally, any specified)
> time stamp won't be hard to implement in rpm --rollback.
> 
> That's mostly a sensible policy, but may have some head-scratching
> consequences when deployed in the Real World, if, for no other reason,
> time stamps (or any other integer used to order) often get incorrect
> values for whatever reason. Any policy is only as good as the data
> which it's given.
Yeah that is an issue that I had not considered.  I would say that in that
case some sort of an integrity check of such things should be done before 
a "system upgrade" occured.  Does RPM keep a record of when the rpm database
was initialized?  If it does and you found any TID's early than this an error
could be flagged when this integrity check was ran.  The response to this is
of course outside of the domain of RPM.

> 
> No matter what, disaster avoidance policies are gonna be needed with
> --rollback, whether (as currently implemented)
> 	No rollbacks composed only of package erasures.
> or
> 	Initially installed packages cannot be rolled back.
> or
> 	These packages will never be erased.
> or
> 	...
>
You know these polices should probably all be supported (you are probably saying
that). 
 
> Another point which needs to be thought through is transaction vs.
> package rollback. Since a TID is used both to
> 	a) order transaction level operations.
> 	b) specify set membership in a particular transaction.
> the Right Thing mostly happens when, say, a package within a given
> transaction has been manually removed before attempting --rollback.
> 
> There are most certainly other difficulties merging manual and automated
> package management, not the least of which is that --rollback is
> impossible if --repackage was not performed when upgrading.
>
Right.  That is why this probably should never be a default behaviour.  
It is self explanatory why --repackage should not be a default (can we 
say the admin did not expect to need that much space in /var/spool/up2date (-;).
 
> 
> The needs are understood, but devising simple/coherent/implementable policies
> is sometimes tricky. As I said privately, I believe that transaction rollbacks
> require disciplined system administration, and tools that assist in enforcing
> policies, that may not exist (yet) for humans typing on the command line.
> rpm has only the mechanism of --repackage/--rollback, but may very well need
> to enforce the rollback policy mechanism as well.
Well, FWIW, the company I work for has a vested interest in seeing that such tools
get built, and I personally want to see them built within the Open Source 
space.  

The way I see it is that RPM is kind of the foundational layer to supporting 
"carrier grade" upgrades (or at least a very important component), but there
are obviously things that need to happen above that.  For instance, especially
in some N+1 configuration, often times various things need to happen before 
a upgrade and after the upgrade that do not belong in a package.  You could 
try to force the package dependencies such that the before package gets
loaded before everything else but that is awkward at best.  Once you start
going into this area you clearly need RPM (the package management system)
to work well, but there is clearly something above it that must exist.

Seeing then that we seem to agree of the need of these different roll back 
policies should I then create a bugzilla report.  Also, if I were to find the
time to add this myself, where might I start looking (-:

Cheers...james