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).
- 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.
So who is going to write the patch to really fix this problem?
In all universes your still going to have issues with SIGCHLD since
rpm clearly needs this when running scriptlets.
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.
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.
Cheers...james
_______________________________________________
Rpm-list mailing list
Rpm-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/rpm-list
