[Yum-devel] Still impossible to exit yum

Panu Matilainen pmatilai at laiskiainen.org
Thu Jul 5 05:46:07 UTC 2007


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 -



More information about the Yum-devel mailing list