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

Reply via email to