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

Re: postun script failure OK ?

On Tue, Mar 04, 2003 at 09:54:08AM -0500, Tristan Van Berkom wrote:
> > Many packages don't necessarily have valid and working %postun scripts,
> > basically because almost nobody tests package erasure. Many, many
> > legacy packages depend on this behavior.
> > 
> 	If you look at my previous mails; you'll understand
> the context in which I ask you this, It is nescisary for
> me to programaticly trap the errors of rpmtsRun(); I've written
> an arbitrary framework to report the reason that a package
> failed to erase/install (built around `enum pkgState' in psm.[ch]).

Sure context and needs of an installer well understood:
	a) don't scribble on stderr/stdout
	b) report all errors back to the calling program.

However, there are already 3 or 4 different mechanisms for 
reporting errors in rpm. The existing mecahnisms need to
be unified, not augmented with yet another mechanism, imho.

Look carefully at rpmps.[ch] before implementing yet another
mechanism please. Parsing details out of strings is more flexible
than inventing yet more structures that lack generality.

> I guess what it boils down to is this:
> /*
>   [ ... cut ... ]
> */
> /* lets say that (rc == 0) here */
> if (!(rpmtsFlags(ts) & RPMTRANS_FLAG_NOPOSTUN)) {
>     rc += rpmpsmStage(psm, PSM_SCRIPT);
> }
> if (!(rpmtsFlags(ts) & RPMTRANS_FLAG_NOTRIGGERPOSTUN)) {
>     /* Run triggers in other package(s) this package sets off. */
>     rc += rpmpsmStage(psm, PSM_TRIGGERS);
> }
> if (!(rpmtsFlags(ts) & RPMTRANS_FLAG_APPLYONLY)) {
>      rc += rpmpsmStage(psm, PSM_RPMDB_REMOVE);
> } 
> /*
>   [ ... cut ... ]
> */

Let's back up a bit.

What do you expect to do if there's an error in a scriptlet? There's
no way to guarantee that a failing scriptlet does not have side
effects that cannot be reverted.

And, if all you want is data/text for display on failure, there's already
a call back mechanism to report payload unpacking errors that could be
extended. (aside: what really needs to be done is reimplement more general
callbacks, but that ain't gonna happen soon, as up2date/anaconda/yum/...
all rely on the existing API no matter how primitive).

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] []