recover from broken yum transaction

[Alexandre Oliva]

On Sep 22, 2008, Seth Vidal <skvidal at fedoraproject.org> wrote:

> On Mon, 2008-09-22 at 01:05 -0300, Alexandre Oliva wrote:
>> On Sep 21, 2008, Bruno Wolff III <bruno at wolff.to> wrote:
>> 
>> > There seems to be two problems you are referring to. One is convenient
>> > remote management and the other is transactions not being atomic.
>> 
>> I'm actually talking about a third problem: that yum starts removing
>> packages just because of an error in reporting progress to
>> stdout/stderr.  Everything else was just context to trigger the
>> problem.

> So let's clear a few things up:

> 1. Once the transaction starts 'yum' isn't doing anything. It is
> reporting what rpm is doing.

It's precisely when yum's reporting fails that the situation arises.

> 2. The only things it is possible for rpm to do is what is in the
> transaction set and the user agrees to perform by hitting 'y'

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.

> So, if you have a case where pkgs are being removed that you have not
> agreed to remove, please file a bug with details.

In the scenario above, would you say you agreed to remove x-N or not?
I.e., does it pass the condition you set for a bug report to be filed?

Could it be the solution is as simple as guarding (exception-wise)
sys.stdout calls in callbacks, to avoid exception leakage that could
get the rpm transaction aborted in this way?  (I'm not sufficiently
versed in Python to know whether write or flush will raise exceptions).

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}
FSFLA Board Member       ¡Sé Libre! => http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}