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 -
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
