At 11:49 PM -0500 12/2/06, Jeff Johnson wrote: >On Dec 2, 2006, at 11:12 PM, Tony Nelson wrote: > >> >> Rpmlib opened up a can of worms when it stole the signals in the first >> place. Sure, it needs something like that in order to be robust in >> the face of stupidity or carelessness, but re-canning still takes a >> bigger can. > >Guy, you don't have a clue ... > >rpm-3.0.x had *CATASTROPHIC* database failures. > >Yes, whole machine, reinstall, scrub to bare disk. > >Which is why the switch was made to Berkeley DB. > >And a concurrent access model was chosen so the widdle python script >kiddies would not have to learn anything whatsoever about database >programming. > >And you want to tell me that rpmlib "opened a can of worms" >because some idiot python programmers have decided to >reopen a Berkeley DB for every header instance in order >to handle ^C?????? No, I did not say that. I said that a library that takes signal handling away from its client application has opened a can of worms, and that RPM needed to do something like that in order to be safe. I did not say anything about Berkely DB, or about earlier versions of RPM. I most certainly did not say, nor do I believe, that the particular method used by yum to regain the use of Ctl-C was correct or workable. I have been promoting a different way to regain the use of Ctl-C. According to my reading of yum, my way is safe for the RPM database, as all the exit paths from yum are equivalent, so if any are safe all are safe. My reason for taking back the SIGINT signal is that RPM gets them even when not in a call to RPM, so they can be delayed for /minutes/ and then pop up after yum's package downloading completes. My understanding is that RPM doesn't need any special action taken on SIGINT; it just needs its database to be closed properly no matter how the application exits, and yum seems to be doing that. I may be wrong about any of this, but I am not a proponent of what yum is currently doing. In any event, the "bigger can" involves something along the lines of letting the client application know in a timely fashion about the signals whether RPM has captured them or not. James' first suggestion looks good to me, but insufficient. I think a function to get the current signal-received flags would also be needed. I don't know how much work Jame's callback would be, and I defer to your judgement. Maybe a function to get the flags would be enough, if there is a reasonable place to use it from yum; I will look into that and make a formal RFE for it if I can come up with a simple patch to yum that would do the job. >This code was *STABLE* even if not perfect until a dweeb made a >change to yum on September 3, 2006. > >I haven't even begun to rip up yum yet. Taking a header instance >and saving it in a dictionary *RELEASING ALL LOCKS* is psychotic. I do not recall defending doing that. Please show me where I have done that so I can apologise for it. I am not the author of yum, I have not written any of the code in yum, and I don't claim to have done so. Writing a yum plugin does not change yum, and my plugin /does not ship/ with yum. I make it available only at my web site (see sig for URL). Umm, in order to help me when I try to read yum to understand what it is doing, are you saying that yum is copying some data from RPM and then assuming that it will not change across unlocking / relocking the database? That is, it uses possibly stale data, but not invalid iterators? And please pardon my ignorance of BerkelyDB; I will work to learn about it. >And delivering FC6 (and soon RHEL5) with this degree of instability, >refusing to upgrade rpm, blabbering on about forking rpm, and accusing >me of sabotaging the source code, when I am not part of FC, nor >@redhat.com, is plain and simply not my problem. I do not maintain RPM or its Fedora package. I am not part of Fedora Project, nor have I said that I was. I posted on this list to ask for assistance with my RPM database-verifying package. I received that assistance from you and others, but I also received a lot of unwarranted and incorrectly aimed abuse. I do not recall "[accusing you] of sabotaging the source code". Please show me where I did that so I can apologise for it. >Whatever I'm doing, you and FC users are highly unlikely to gain any >benefit whatsoever. That seems strange. In any event, you have been somewhat helpful to me and you are clearly doing work to make RPM more robust in the face of both happenstance and stupidity, and I thank you. -- ____________________________________________________________________ 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
