On Wed, 4 Jul 2007, seth vidal wrote:
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?
That would be true if rpm didn't allow concurrent access. But the thing is, once you permit simultaneous read and write to the db, you have to worry about locking with readers as well. Otherwise another process could, say, erase the header you were just reading. Oops.
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.
Like said, mtime can be used but there are probably other ways as well. Let me see if I can come up with a better scheme.
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". :)
Sure, it is. That's just one example of rpmlib and rpm cli being way too mixed up - exit() at termination signal happens to make sense for rpm cli, but not for (all) API users. That's the reason there's "proper separation of cli and library" in the rpm.org todo.
We've some chainsawing to do... <evilgrin>
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.
Yup... I have some further ideas that I'll need to check validity of in real world that may help this without need for large changes, part of todays agenda for me. Oh and FWIW, I'm not worried about having to make large changes to rpm per se, but right now I'm looking for a way to do it minimalistically enough to be safe for 4.4.2.x.
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? :)
We could always rewrite it in C++ ;)
- Panu -
_______________________________________________
Yum-devel mailing list
[email protected]
https://lists.dulug.duke.edu/mailman/listinfo/yum-devel
