On Mon, 22 Sep 2008, seth vidal wrote:
On Mon, 2008-09-22 at 15:47 -0300, Alexandre Oliva wrote:
Right. The problem is when you agree to "update x", i.e., "install
x-N+1; remove x-N', and it fails (say, in case sys.stdout.write or
sys.stdout.flush raise an exception within callback) before it gets to
install x-N+1. Then RPM still ends up removing x-N, although
sometimes what I saw looked more like a --justdb removal (files and
libraries left behind, but package gone from the rpmdb), but in
others, as in the most recent case, elfutils libraries were really
gone.
The above really isn't possible. If you can recreate this then please
file a bug. File the bug against rpm but please cc me on it.
I wouldn't call it impossible, in fact I just managed to reproduce it with
this:
--- a/yum/rpmtrans.py
+++ b/yum/rpmtrans.py
@@ -374,6 +374,7 @@ class RPMTransaction:
self.total_installed += 1
self.complete_actions += 1
self.installed_pkg_names.append(hdr['name'])
+ raise IOError
return fd
else:
self.display.errorlog("Error: No Header to INST_OPEN_FILE")
Without having yet looked deeper into it, it probably comes down to this
in rpmtsRun():
/*
* XXX This has always been a hack, now mostly broken.
* If install failed, then we shouldn't erase.
*/
The hack in question is easily fooled, and so rpm is ultimately
responsible for the damage that results from yum code tracebacking in the
transaction callback. Rpm needs fixing (I'll go look into it right now),
but I'd suggest you go and comb through the ts callback code in yum - you
do NOT want it tracebacking, especially on "trivial" things like
sys.stdout operations failing.
- Panu -
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
