On Sep 22, 2008, Seth Vidal <skvidal@xxxxxxxxxxxxxxxxx> wrote: > On Mon, 2008-09-22 at 01:05 -0300, Alexandre Oliva wrote: >> On Sep 21, 2008, Bruno Wolff III <bruno@xxxxxxxx> 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} -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
