On Oct 3, 2009, at 5:13 AM, Ralf S. Engelschall wrote:
On Sat, Oct 03, 2009, Armin B. Resch wrote:
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:
(0) Choose a version of Berkeley DB for OpenPKG python. Internalize
a plain vanilla
version of Berekeley DB with a single API and backward db format
compatibility.
(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
(6) make a snapshot by storing all Source RPM files (*.src.rpm) which
you used to created your software stack into a local repository,
index them there with "openpkg index" and deploy your software
stacks from there via "openpkg build -r <url>". This way you are
independent of our OpenPKG upstream packages (which intentionally
are a fast moving target in order to continously track the latest
vendor versions).
All source files in OpenPKG need to be forked in order to achieve
an upgrade of Berkeley DB?!? C'mon, be serious ...
73 de Jeff
______________________________________________________________________
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
