Re: rollback hosed by install/upgrade without --repackage...

[Jeff Johnson <jbj redhat com>]

On Mon, Jan 27, 2003 at 01:48:12PM -0500, James Olin Oden wrote:
> > 
> > On Mon, Jan 27, 2003 at 11:33:09AM -0500, James Olin Oden wrote:
> > > If one installed a package or two without --repackage, I would assume
> > > that if one later used the --rollback option to go back to a time previous the 
> > > update/install of these packages, these packages that were not installed/upgraded
> > > with the --repackage option would not be part of the rollback.  And in this
> > > case my assumptions hold true.  What I find troubling is that any other rpm 
> > > transactions previous to the install of these rogue packages and post
> > > the rollback date, are not rolled back.  It is as if the first time someone
> > > installs or upgrades without --repackage, any knowledge of transactions 
> > > previous to this rogue transaction is forgotten.  This I find most disconcerting.
> > > 
> > 
> > As warned, use of --repackage/--rollback on the CLI requires exactly perfect
> > system administration.
> So are you saying that the problem would be avoided by using the API, or through
> some python/perl binding?  
> 

No, I'm saying that --repackage/--rollback in rpm is pure mechanism and that
policy needs to come from somewhere else. ATM, up2date has better policy.

For example, --rollback is as good or bad as the contents of
	/var/spool/repackage.
Lose that directory, or pollute it with "other" packages, or forget to add
--rollback executing some CLI command, or run some program like
redhat-config-packages that has not a clue about --repackage, and you're
sh*t-out-of-luck.

Yes, rpm-4.1 has the ability to force --repackage from configuration no
matter what. That's *still* not enough to handle the problems mentioned.

> On another note, I am not asking that the CLI or RPM solve cockpit error 
> problems, just want it to make a best effort.  Imagine the following scenario.
> We have machines deployed through out the world that are 
> handled in a near perfect way concerning system administration.  We tell the 
> customers of these "appliances" that they should stay off, or problems could occur.
> Occasionally one them decides they know better than us (and who knows, perhaps
> they do) and they get on the machine and do something they really should not.
> In particular if that something is install an RPM that was not on the system
> before (perhaps a monitoring tool or something), then we can't do rollbacks
> to any point before the customer introduced this rpm into the system.  Eventually
> we may figure out that the customer (or a new employee) has done something
> unpleasant, but even if we do figure out who oopsed blame may still be 
> pointed to us corparately.  
> 

Again, and again, I'm not saying that you can't be successful using --rollback,
but you're going to need tools -- other than rpm itself -- to assist with the
task of "perfect system administration".

I already know about any number of failure modes. IMHO, rpm needs to be
connected to a universe of packages, not mess with local --repackage and
mixed up2date/anaconda/rpm execution creating random horkage problems.

Given access to a universe of all possible packages, --rollback is as
simple as keeping track of a time stamped manifest.

Without being connected to a universe of all possible packages, --rollback
is an overly complicated hack that cannot solve the problem precisely and
completely.

> So it would be nice, if RPM could do a best effort approach rather than not even
> trying.  But perhaps I am not understanding the problem fully.
> 

There's no such thing as "best effort" wrto policy when rpm --rollback has
only mechanism, and imperfect mechanism at that.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@redhat.com (jbj@jbj.org)
Chapel Hill, NC