On Oct 1, 2009, at 12:15 PM, Bill Campbell wrote:
On Thu, Oct 01, 2009, Armin B. Resch wrote:
Fellow OpenPKG-lers,
My python build failed after the most recent db rebuild
(db-4.8.24.0-20090920.src.rpm). After some googling, I came across
this bug
report + patch:
http://bugs.python.org/issue6949
I appended the suggested patch to OpenPKG's python.patch and the
build now
works for me.
Can we include the patch in the central OpenPKG repo?
As a general rule, it's never a good idea to update the Berkeley
database routines in a working system as they are (a) a horrible
kludge of spaghetti code with APIs that differ even between minor
release changes, and (b) they're deeply embedded in far too many
things to do it safely.
If you want to see some truly messy code, look at the db routines
in perl or python sources to see how many #if statements are
necessary to handle the differing APIs.
Well here's the positive expression of the same idea (which applies
to any common/widely used system resource like OpenSSL or NSS or
PHP or Python, not just Berkeley DB)
Try embedding Berkeley DB into any/every application to uncouple
from the LCD approach imposed from having everything on the "system"
in lockstep.
That is -- in fact -- what is/was recommended by Oracle (nee
Sleepycat) for almost
a decade now. And unlike the other examples (Python 3000 anyone?),
Berkeley
DB is designed to be embedded with a small footprint amd symbol
uniqification.
No #if's need apply. And perl/python script kiddie hacks to pretend
"portable" aren't the right approach. What should be done is to embed
Berkeley DB directly into python/perl to avoid the need for all
the fuss and muss. The decision of "Which Berkeley DB?" quickly
morphs to "Python 3000 (or not)?" or "perl-5.003 (or not)?" etc etc etc
73 de Jeff
______________________________________________________________________
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
