On Jun 28, 2007, at 12:06 PM, Arkadiusz Miskiewicz wrote:
On Thursday 28 of June 2007, Jeff Johnson wrote:
On Jun 28, 2007, at 2:06 AM, Ralf S. Engelschall wrote:
Fair enough! It certainly is a difficult balance between avoiding
the
trouble with lusers and still allowing packagers to build RPM
with an
external Berkeley-DB _without_ having to patch the RPM sources.
The only patch is the robust mutexes. There's likely a vector in
Berkeley DB that can be overridden, and the POSIX shared mutex
locking can be carried privately within rpm if external db is
absolutely desired.
Where is that patch? We at PLD don't like internal libs, we prefer
to patch
external ones.
The patch is likely harmless, but is not generally acceptable. One
cannot
just inherit a previously locked mutex/futex without cleaning up side-
effects of
the lock. For rpmdb accesses, the side-effects are sufficiently
predictable,
and with --rebuilddb in place, the risk is acceptable for the gain of
not having
to reboot a machine to clear a stale futex.
Generally those conditiions do not apply.
There is a db-4_5_20 tag in cvs, the patch can be generated from a
checkout,.
The patch was also posted on <[EMAIL PROTECTED]> like
last November.
A better patch, overloading runtime vectors from within rpm, is
likely better than
just whacking into libdb. But a global enabler in system db is also
easily achieved.
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org