Bug 463999

Description of problem:
The problem is outlined in this recent thread on fedora-devel:

https://www.redhat.com/archives/fedora-devel-list/2008-September/msg02063.html

...but basically if an exception occurs in the yum RPMTransaction callback,
then rpm can go insane and run the "delete old versions" part of the updates
without having run the "install new versions". An exception can be generated on
I/O if the ssh connection dies of the person running the yum update command.
 So if you are updating glibc over ssh and the network goes away, rpm can
remove the C library and thus. kill the machine.


We have a piece of python code which ends up calling code in librpm. The librpm code calls back to the python code for certain things, such as taking care of opening file descriptors for packages that we're about to install. So far so good, nothing too special here.

But... the unthinkable happens and there's a bug in the callback code - say it returns the string "fool you!" instead of being a good boy and handing us a file descriptor integer. Rpm notices this, gets sulky (quietly discarding the exception) and simply doesn't perform the callback to python anymore on subsequent events. Now, remember that the callback is supposed to, among other things, hand opened file descriptors back to rpm for performing package installations. If the callback doesn't perform that, nothing will and there will be nothing to install. Oops. But rpm goes on a zombie rampage:

    "I shall finish my dirty deed and no dead python is going to stop me!"

And this is where the "always been a hack, now mostly broken" part strikes. If that part functioned correctly, nothing *too* bad would happen. As it is, rpm can end up erasing half the system in the worst case. Fixing the "install failed so don't erase" algorithm is one thing, and not entirely trivial. But in this case we never ever should've gotten that far, because the process should've terminated a long, long time ago.

The good news: getting exceptions in python callback(s) just dump a traceback and abort is trivial to do.

See also yum BZ 463447 for the associated yum fix for this issue. 

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info: