[Yum-devel] [PATCH] If verifyTransaction detects that a removal was not successful, it will now set the output_state of the pkg to TS_FAILED. BZ 661962

Panu Matilainen pmatilai at laiskiainen.org
Thu Jun 16 05:43:09 UTC 2011


On 06/16/2011 08:21 AM, James Antill wrote:
> On Wed, 2011-06-15 at 16:37 -0400, Nick Jacek wrote:
>> Install actually works correctly, so I don't think anything should be
>> changed a few lines up.
>
>   Yeh, but if it ever doesn't then we want the check to find and fix it.
>
>>    I believe this is because where these errors happen, functions like
>> _scriptError etc. get called in rpmtrans.py.  They have a few lines
>> like
>>
>> if total:
>>              msg = ("Error in %s scriptlet in rpm package %s" %
>>                      (scriptlet_name, package_name))
>>              if txmbr is not None:
>>                  txmbr.output_state = TS_FAILED
>>
>> The difference is that in the case of install, txmbr is a transaction
>> member, but in the case of remove, txmbr is None, so the output_state
>> isn't set to TS_FAILED, even thought it is in the case of an install.
>> It seems to me that ideally these functions would set TS_FAILED for
>> both installs and removals, but in these functions txmbr is set via
>>
>> name, txmbr = self._getTxmbr(h)
>
>   Yeh, we should work around that when we can ... as it's a long standing
> rpm API wart.

Yup (sigh). I was about to say verifyTransaction() could use te.Failed() 
to get the real status of an element without having to guess but seems 
rpmteFailed() never got exported to the python bindings. Funny, I 
could've sworn I added it back then...

Oh well, better late than never - examining the actual elements' status 
is necessary for catching situations where rpm skips an element entirely 
(because of "parent" element failure) in which case no callbacks will be 
issued for yum to grab.

	- Panu -


More information about the Yum-devel mailing list