On Wed, 2007-07-04 at 23:40 +0300, Panu Matilainen wrote: > Safe enough, I suppose. You still don't want to do it like it was > previously, eg each and every rpmdb lookup reopens it. So you'd want to > run most of the depsolve with db open (only close for filelist downloads) > and thus ctrl-c blocked, but that's far less annoying than the > uninterruptable download - the ctrl-c will be noticed sooner or later > anyway.
It would be nice if there was a way to tell rpm: This process does not write to your rpmdb in anyway, therefore you do not need to catch signals b/c there's no reason to worry about db integrity if I'm NOT DOING A WRITE! :) I'm not insane in thinking that behavior of grabbing all the signals anytime we read is broken, right? > > 2. is there a db-version or journal or some other information in the > > rpmdb we can use to know if it has been changed? > > One possibility would be just looking at file modification times but I've > a feeling there was some nicer way hinted by Jeff a long time ago in > another discussion... hmm... yup: > > "I can suggest several means to tell whether an rpmdb has changed > that don't rely on file mtimes. Retrieve the monotonically increasing > package instance from Packages with key 0x00000000 for example. > That value changes with any addition to an rpmdb, perhaps not gud > enuf if you want erasure changes too." > erasures would change header ids. So, yah, I need to know about them, too. A shame there isn't some sort of journal that I could just check the index of the journal and see if it incremented. > Avoiding getting more of those "rpmdb is stuck and blows up" bugzilla > tickets is a pretty strong motivation now :) good luck with that. :) > Didn't experiment with putting it into rpm-python for real yet, but > getting the traceback trapped at C-level was easy enough. The rest of the > trail leads to ... dumdumdum ... signal handling, and the code path there > that automatically does all the necessary cleanup ends in an exit() deep > from rpmlib. So I'm not much of a C coder so maybe I'm confused but I thought exit() deep inside a library was "BAD THING" and should be "DISCOURAGED". :) > In practise it means a custom sys.excepthook couldn't be > called while rpmdb/iterators are active. Not a problem for yum where the > output is text-based anyway (the traceback can be printed), but for things > like pirut which probably have their own handler to give pretty tracebacks > to GUI, it is. right - not so much on the joy for us. > Similarly, exposing the rpmdbCheckSignals() call to the python bindings is > trivial (and rpm5.org actually has it already), but has the very problem > as described above: any call to rpmdbCheckSignals() will either return > normally or exit() with no return to calling code. good times. > It could be enhanced in a API-compatible way with a wrapper that works > like the old one I suppose... need to scratch head some more to figure how > to best handle it. How about we just nuke it all from orbit and start over? :) -sv _______________________________________________ Yum-devel mailing list [email protected] https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
