Thanks, guys, for your insights wrt the bsddb module which appears to be deprecated, possibly in part due to the pitfalls you described. I guess one way forward to ameliorate API ugliness was to abstract it behind a separate python package (http://pypi.python.org/pypi/bsddb3/4.8.0). Perhaps, under Oracle's auspices, the Berkeley db release cycle is better managed, too.
As a relative OpenPKG newbie, my inquiry is more mundane and general in nature, though, because my use case is this: I have a stack of open source products which I built up using OpenPKG and all its components play nicely together. I periodically update the instance which - thanks to rpm - 'memorizes' the product-specific build options as exposed by the spec file. The plan is to 'snapshot' the product semi-annually or so. But, as this python-bdb issue exemplifies, there are limitations to this approach of build automation, because here we have a situation in which a build of the same package/version/build-option suddenly fails because a dependency changed. So, what should be the proper approach and who takes ownership of the issue? To my mind, the options are: (1) Do nothing - hope for the downstream dependency to fix the issue in a subsequent release or otherwise let the spec file atrophy and the user deal with it (2) Pull the offending package (e.g. db-4.8) from the central repo and revert to the previous version (3) Remove the offending build option (e.g. for python, remove with_db) (4) Morph the build option into a no-op as far as build configuration goes, but print a DISCLAIMER to stdout with instructions on how to remedy the situation (e.g. deprecated - install python-bsddb3) (5) Apply a patch Any others? How were similar issues dealt with in the past? TIA, -ar > -----Original Message----- > From: openpkg-users-ow...@openpkg.org [mailto:openpkg-users- > ow...@openpkg.org] On Behalf Of Jeff Johnson > Sent: Thursday, October 01, 2009 12:02 PM > To: openpkg-users@openpkg.org > Subject: Re: Python-2.6.2 --with=db > > > 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 ______________________________________________________________________ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
