[Yum-devel] Re: [Yum] yum 3.2.11 (fedora rawhide) erroneous success message
Panu Matilainen
pmatilai at laiskiainen.org
Mon Feb 25 10:59:49 UTC 2008
On Mon, 25 Feb 2008, seth vidal wrote:
> On Sun, 2008-02-24 at 12:32 +0200, Panu Matilainen wrote:
>> 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. :)
Me too, me too... Yet somebody somewhere might be using that distinction
so changing means potential breaking :-/ Guess why I want to start a fresh
set of python bindings :)
>
>> 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?
At least one of the perl-RPM variants will go kaboom if new ts callback
event type is added. That one would be easy to fix of course, but if
there's one thing that breaks who knows how many others... so it's not
really an option for 4.4.2.x, rpm.org head already has it though.
Rpm already has an "error event" callback via rpmlog, only it's not
exposed to python at all. That's about to change in the next major version
but right now, for 4.4.2.x and older, I think your best bet is just to
look at the None vs [] value on ts.run() return :-/ FWIW that's more or
less what apt does (ignoring C vs python API differences) and reports
"some errors occurred within transaction" in these cases. It's not much,
but it's still better than saying "everything ok" when its not.
- Panu -
More information about the Yum-devel
mailing list