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

[Jeff Johnson <jbj redhat com>]

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