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

Re: postun script failure OK ?

> 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]).

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

we know that the line "if (rc) break;" in the first and second
`if' will result in multiple entries in the DB of the same
package; so its just as desireable that PSM_TRIGGERS doesn't
break the database. At this point; we know that something
failed during the package erasure but we can return an
error code without breaking the database.

if we PSM_RPMDB_REMOVE after failing PSM_TRIGGERS; will that
cause unexpected errors ?

if we PSM_RPMDB_REMOVE after failing PSM_SCRIPT; will an error
code from rpmpsmStage() (and consequently rpmtsRun()) cause
other unexpected errors ?

> (sorry, been backporting rpm-4.2 to rpm-4.1.1 for several days)

no problem at all.


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