[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 04:22:49PM -0500, James Olin Oden wrote:
> > > 
> > > Nah, booleans rot too.
> > > 
> > > Try
> > >     rpm -qa --qf '%{name}\n' | sort | uniq -d | grep -v kernel
> > > That's most, if not all, of the partial installs. Prune to taste.
> > This works if a previous verison of the RPM was installed on the system.  A
> > new rpm that partially installs will fail this test.
> > 
> > While we are on the subject, I found a real bug concerning this and 
> > the --rollback feature.
> > 
> > Say I upgrade in the following way:
> > 
> > 	rpm -Uvh --repackage A.rpm B.rpm
> > 
> > and say A paritially installs.  At that point
> > I would receive an error, and would want to rollback, so I 
> > do a rollback:
> > 
> > 	rpm -Fvh --rollback '1 hour ago'
> > 
> > At this point it does nothing.  I would expect it would install the repackaged
> > 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.   
> > 
> > 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.
> 73 de Jeff
> -- 
> Jeff Johnson	ARS N3NPQ
> jbj@redhat.com (jbj@jbj.org)
> Chapel Hill, NC
> _______________________________________________
> Rpm-list mailing list
> Rpm-list@redhat.com
> https://listman.redhat.com/mailman/listinfo/rpm-list

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