At 6:55 AM -0500 12/1/06, Jeff Johnson wrote: >On Nov 30, 2006, at 9:53 PM, Tony Nelson wrote: > >> At 6:24 PM -0500 11/29/06, Jeff Johnson wrote: >>> On Nov 29, 2006, at 6:20 PM, seth vidal wrote: >>> >>>>I'm not saying yum does guarantee those. I'm asking why does the above >>>>cause the rpmdb to have errors? >>> >>> Dunno (yet), there are likely several intersecting causes. >>> >>>No matter what, yum should go back to last known good. It's easier >>>debugging, and seemed to work at some point in time. >>> >>>The only reason that I've heard for the open-extract-close change is to >>>handle signals within yum, and that can easily be achieved in other >>>ways. Nasrat has details. >> >>If handling of Ctl-C is the main reason for yum's new repeated RPM >>database opens / closes, I have a suggestion or two. >> >>RPM wants to catch the signals so it can be sure to close the RPM >>database properly in all cases. Yum also tries to close the RPM database >>properly in all instances. It should be enough if yum does it. >> >>1) Yum could steal back the SIGINT handler, as I do in my Stablemirror >>yum plugin <http://georgeanelson.com/stablemirror.htm> (for FC5 yum, not >>really needed anymore with the mirrorlist improvements). It calls >> >> signal.signal(signal.SIGINT, signal.default_int_handler) >> >>in an override of _mirror_try() in a subclass of MirrorGroup, to >>repeatedly steal back the SIGINT signal. Yum could do the same right >>after opening the RPM database, but also in other places, as I think that >>RPM will sometimes take the signals again later just to be "safe". This >>can be done now. > >What does signal.default_int_handler do? Exit? It does the "Python thing" of raising a Python Exception. SIGINT produces a KeyboardInterrupt exception. Any unhandled exception will terminate a python program, but Yum handles KeyboardInterrupt, and either does something useful, such as moving to the next download mirror (that happens in a library), or it terminates gracefully, closing the RPM database cleanly. My understanding is that the changes to yum to repeatedly open and close the RPM database are to work around RPM's seizing of SIGINT. I believe this proposal is a cleaner, safer, and more effective workaround for that issue. (More effective in that fewer SIGINTs are eaten by RPM.) I have not received any complaints about Stablemirror from its (very few) users other than that it doesn't work at all on FC6, where it is really no longer needed. >If so, that explains why your database is in need of so much >verification. No, yum is careful about closing the database when it exits. My reading of what RPM does on receipt of a signal and what yum does was that they are equivalent. And it is an ASSumption ;-b that my RPM database needs more care than others. I'm merely taking better care of it than most. 8-) >> 2) RPM's developers could be asked for a new API to tell RPM not to >> take certain signals. This could be done for FC7. > >You ought to make the suggestion on <fedora-devel> and on <rpm-devel> >mailing lists. Well, at the moment, it seems that the two people most involved, you and Seth, are communicating here. If my idea is acceptable, you and Seth will say so, and if Seth requests me to I will poste elsewhere and file a RFE against RPM. If not, my idea won't be used, so a request to enhance RPM would be a waste of your time. Still, if you ask, I'll do those things. Seth doesn't always respond to my posts (even if they are in reply to a reply of his to one of my posts). When he does respond, it is usually to day that whatever I've proposed is an unclean hack. He may think that it is cleaner for yum to repeatedly open and close the RPM database than for it to steal back the SIGINT signal, but I don't know. >While you're at it, why don't you create bugzilla reports for every >Red Hat, SuSE and Mandrive product as well. That would be inappropriate, as I don't use those products. -- ____________________________________________________________________ TonyN.:' The Great Writ <mailto:tonynelson@xxxxxxxxxxxxxxxxx> ' is no more. <http://www.georgeanelson.com/> _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/rpm-list
