On Sun, 2008-02-24 at 12:32 +0200, Panu Matilainen wrote: > Funny you should say that, the "Error unpacking rpm package <pkg>" message > in the above comes from yum not rpm :)
:) > Scriptlets failing are another matter as no callback error is issued in > rpm 4.4.x or older. It'd of course be possible to backport the relevant > bits from rpm.org head to 4.4.2.x to do so, but I'm not very comfortable > about adding new callback types there to avoid breaking 3rd party > callbacks in a maintenance release. > But .. there actually is a way, even in present, for python to see if > transaction went all peacefully or not (just happened to notice). It's > just not exactly "obvious": ts.run() returns None if everything went ok, > but an empty list if errors occurred within the transaction (and a list of > rpmps problems if there were issues like disk space problems preventing > the transaction from running at all). hahah. None is distinct from an empty list in terms of meaning. I love rpm sooooooooooo much. :) > So at least you can give an indication at the end of transaction whether > the user should look for errors in the transaction log or not, instead of > just saying "Complete!" no matter what happened: > > errors = self.ts.run(cb.callback, '') > if errors is None: > # all went well > elif len(errors) == 0: > # this is return from a transaction that completed but contained > # errors like scriptlet failures > else: > # this is return from pre-transaction checking with errors > # containing list of rpmps problems that prevented transaction > # from starting > > Oh and I do agree that's just a terrible interface, need to do something > about it. An easy in many ways option would be to stuff any errors within > the transaction to rpmps items for easy viewing post-transaction. > There would have to be some easy way to distinguish pre- and > in-transaction classes of errors, as for pre-transaction errors you might > want to fiddle with the set or add extra problem filters and restart. > Hardly rocket science but will mean changing API or at least it's > semantics somewhat. I understand - would it be reasonable to just have an error_event callback? That way you can signal and do _something_ in the callback if there is an error? -sv _______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
