On 12/1/06, James Olin Oden <james.oden@xxxxxxxxx> wrote:
>
> 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.)
And racy. Its not really solving the problem. In general its been my
experience that signal handlers in libraries is a bad thing. That
said librpm is IMO a very special library. The issue is that there
is no way for rpm to know (today but not maybe tommorow) what the
consumers needs are in the event of a signal. That said there should
be no way for a consumer to know what needs to be done by librpm in
the event a signal is caught (the particulars that is). So what do
you do.
Probably the right thing to do is provide one of two things (or both):
- have librpm provide a method for a consumer to register a
callback to be used
in the event a signal is caught (probably sending what signal and
what rpms
action will be, such as exiting or not).
I can add the callback if necessary, but there's a fair amount of overhead
that would be needed ...
- Have rpm have a single method to call in the event that the
program is exiting.
This would require rpm to internally track all transactions in
existance in a
processes, or at least all DB connections.
... rpmlib is already keeping track of the list of all opened rpmdb's,
no biggie ...
So who is going to write the patch to really fix this problem?
I am. I'll salt in checks of rpmsqCaught on exiting method exits,
and throw the keyboard exception when any of the ^C usual candidates
occur.
In all universes your still going to have issues with SIGCHLD since
rpm clearly needs this when running scriptlets.
Sssshhh! Lest "Free the SIGCHLD!" becomes the next droning chant ...
There are already yum bug reports being dumped on rpm because scripts,
indeed, fail, with output to stderr, and so its a rpm, not a yum, problem
to deal with the messed up progress bars.
>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.
YUM should not have to know there is a database to close really. This
is not a yum criticism necessarily. RPM hides access to the database
behind an rpmts (transaction), and an rpmtsUnlink() of the transaction
will automatically close the database. But what you really need is
better coperation between yourself and rpm without adding a very tight
coupling between yum and librpm.
Which is why I removed all db methods from the rpmlib API, and
tried to indicate that Ya really don't have to call ts.CloseDB() in
python __doc__ strings. Been there for years ...
> My reading of
> what RPM does on receipt of a signal and what yum does was that they are
> equivalent.
>
You shouldn't assume that, at least if your trying to treat librpm
like a black box.
> 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-)
>
Please keep it professional and mature. Together with all parties
showing mutual respect we can solve problems.
Thanks for the help, you're much nicer than I am ...
73 de Jeff
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
