On Dec 3, 2006, at 3:49 PM, Tony Nelson wrote:
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.
Look -- in case you can't tell -- the problem of ^C handling wrto yum
has been around for years.
And furthermore -- just like with --verifydb handling -- all the
peices have been in place for years.
The issue is getting yum to use what is already implemented.
It's already possible to set signal handlers outside of the signal
handler mechanism that is already implemented in rpmlib.
I do not need someone who has not looked at the code, nor does not
know the history, to tell me what needs to be done. Much of the
implementation
already exists in rpmlib, been there for years.
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.
Don't take it too personally, just look at the code some, and think a
bit more,
before answering. ;-)
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.
Neither do I. I find the situation quite ironic, and the lack of
stability
in FC6 (and perhaps RHEL5) disturbing.
Unfortunately my RPM professional reputation is coupled to FC's and
RHAT's,
so I *have* to care.
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.
You did not, others have.
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.
Thank you for thank you, the same to you. I wouldn't have
internalized --verifydb
if you hadn't shown up ;-)
73 de Jeff
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
