[Yum-devel] Re: [Yum] yum 3.2.11 (fedora rawhide) erroneous success message

[Panu Matilainen]

Taking this from yum-users to -devel...

On Mon, 18 Feb 2008, seth vidal wrote:

>
> On Mon, 2008-02-18 at 16:43 -0500, Matthew Miller wrote:
>> On Mon, Feb 18, 2008 at 08:28:54AM -0500, seth vidal wrote:
>>>> This is with yum-3.2.11-1.fc9.noarch and rawhide. Look how it says it
>>>> updated xulrunner when it really didn't. Is skip-broken to blame?
>>>>
>>>>   Updating  : xulrunner                    ######################### [1/2]
>>>> Error unpacking rpm package
>>>> xulrunner-1.9-0.beta3.22.nightly20080215.fc9.i386
>>>> error: unpacking of archive failed on
>>>> file /usr/lib/xulrunner-1.9pre/dictionaries: cpio: rename
>>>> Unable to send message to PackageKit
>>> Yah what a fun time. So, unless I'm mistaken, rpm is failing to handle
>>> something in the installation of that package and it is not reporting it
>>> as fatal to the transaction. We have this problem, often, with
>>> scriptlets aborting in %post.
>>
>> I probably should have pointed this out, but I know what the specific
>> problem is -- in the old package, /usr/lib/xulrunner-1.9pre/dictionaries is
>> a directory, and in the new one it's a symlink. There's some sort of
>> longstanding RPM bug in this case.
>>
>> If you look in the middle of all of the output I sent, deleting the
>> problematic directory with rm -rf before running yum causes everything to
>> work as it should.
>>
>> So, yeah, while the underlying bug is concerning, I'm, for the purposes of
>> this mailing list, mostly worried that yum appeared to think that the
>> upgrade succeeded when really it failed.
>>
>
> yes, rpm gives us no way of knowing otherwise in the python layer,

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

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.

 	- Panu -