Re: SUG: Automatic RPM database verification and repair

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Dec 3, 2006, at 11:12 PM, Tony Nelson wrote:


While I think the code is insanely clever, and I'm quite pleased
that rpm is surviving as well as it is in spite of unanticipated
and bizzarre uses of the implementation, the code is solving
entirely the wrong problem, and triggering a lot of instability.

I don't quite see that this code is a problem. It only runs at task time
(not at signal time), when the object is being reclaimed by the Python
interpreter. It should be like any other call to close the database. It
can't happen inside a call to rpmlib (unless there is more than one
thread).  Am I misunderstanding the issue?


The intent of
    ts.CloseDB()	# <-- this is unnecessary btw
    del ts
is to keep rpm from "stealing" signal handlers, on last
rpmdb close the original signal handlers are lazily restored.

I have heard no other reason for the "del ts" change, transaction.py
used to have a persistent transaction which kept an rpmdb
open as long as needed.

Which was higher performing in some yum version, I still can't find
Panu's measurements though.

There are other means to throw an exception on a signal.

73 de Jeff

_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list

[Index of Archives]     [RPM Ecosystem]     [Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]

  Powered by Linux