[Yum-devel] Still impossible to exit yum

[seth vidal]

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