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

Re: RPM's that fail in %post...

On Wed, Jan 15, 2003 at 09:38:39PM -0500, James Olin Oden wrote:
> > > version of B, but it does not.  I would say this is a bonified
> > > bug, that would effectively make the use of the transactional
> > > rollback useless to us.
> > 
> > The only answer atm is to make sure your packages don't partially install.
> > 
> > For the case you mention, failure of %post, this is trivially tested
> > by installing the package into a chroot or on another system first to
> > detect the %post packaging failure before you start upgrading lots of
> > systems.
> >
> While performing the tests you suggest is par for the course, that does not
> solve the problem of the test case you miss.  Testers and developers
> try very hard to test packages, but inevitably a bug gets through.  If 
> you are in a telco environment where a rollback/backout is mandated
> it is not an option to write code that does not prepare for a partially
> installed package.
> Also, while I agree that RPM cannot do everything, I would expect in the 
> above scenario that the package that did get installed properly would be
> able to be rolled back.  I would not necesarily think that the partially
> installed package would do the same.   

I don't disagree, but rpm, and particularly rpm-4.0.4, is nowhere near
a complete, functional, robust --rollback implementation on the CLI.

I have never claimed otherwise.

> > > 
> > > Just so you know I am using rpm 4.0.4 on Advanced Server 2.1.
> > 
> > Again, the --rollback option in rpm-4.0.4 requires absolutely perfect
> > system administration, and is mostly mechanism, not policy.
> >
> Which we take great pains to ensure on or systems, but the fact is 
> eventually something slips through, and we have to code for that 
> eventuallity.  Essentially this leaves us with two backout methods:
> 	- If rpm returned with an error, do a manual unravelling of the
> 	transaction (i.e. uninstall the rpm's in the manifest that 
> 	actually where installed, and resinstall the older versions).
> 	- If rpm returned without error, we can use rpm's --rollback
> 	option at a later date.
> Its not very pretty.  I would much rather RPM rollback what was installed
> properly in the transaction, and then we only have to clean up (probably 
> by hand) the mess left over from the partial packages. 
> The bottome line is I believe this is a bug in the rollback feature that
> makes it mostly useless to us.
> > There's somewhat better policy in latest up2date code, but it's gonna be
> > a while before --rollback is robust.
> >
> And of coruse up2date does not operate from a CDROM environment, and requires
> some interaction with a database accross a network.  This is not an option
> for most of our customers.

I pointed you at up2date code because you were asking about python bindings
and want better rollback policies implemented. Whether up2date supports CDROM
installs is a different matter.

The policies (some of which were suggested by you) will be back ported to
the rpm CLI after gaining experience with rollbacks through up2date.

73 de Jeff

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

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