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:
>
> (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).
Ralf S. Engelschall
r...@engelschall.com
www.engelschall.com
______________________________________________________________________
OpenPKG http://openpkg.org
User Communication List openpkg-users@openpkg.org
