[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