[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



> 
> On Mon, Jan 27, 2003 at 01:48:12PM -0500, James Olin Oden wrote:
> > > 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.
> 
OK, I guess I am just plain confused.  I have been of the mindset that if one
was going to do a transactional rollback they would either do --rollback
or call rpmRollback() directly.  I had not imagined that you might desire
that users of rpm (i.e. developer/developer admins in this case) would in 
essence either through the commandline or via the lower level transaction api
build their own rollback.  Is this what you are saying?  

> 
> 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.
One that is timestamped, and then you have to emulate the logic in rpmRollback
by walking down the transactions until you are less than the time stamp.  
I think I understand.   

> 
> There's no such thing as "best effort" wrto policy when rpm --rollback has
> only mechanism, and imperfect mechanism at that.
I am still not totally convinced, but I have looked at the log of rpmRollback(),
and now I think I know why it fails.  Essentially, you are looking for each
rpm in a particular transaction to rollback, and for each rpm you try to find
its repackaged package.  If that is not there, you bomb (gracefully (-;).

I guess what I am ultimately looking for is some sort of way to communicate
policy to rpm.  For instance, in the case that the repackaged package is not found
I might want to ask rpm to go on and add the other rpm's for which it can find repackaged
packages.  The default behaviour of course being to just bomb out.  Essentially,
I would want it to provide a few sane policies.  There will always be the case
where it just makes better since to have the person code their own rollback
but it will always be nice if one can do something like:

	rpm -F --rollback 'some_date' 

from a script, and pretty much expect the right thing to be done.

Thanks...james





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index] []