Hi Ralf, Thanks for that. Option 6 is not unlike the first one, then. Your suggestion is interesting, though. I do use the -r option against a local mirror, but would have dealt with situations like that by simply adding the offending package to an exclusion list on the build command (after reverting the offending package to the prior state, naturally). What are the benefits of creating a separate repo+index? Run-time dependencies?
As a general rule, would it be accurate to say that you don't try to patch a package unless it's an OpenPKG-induced build failure (package builds if pulled from the vendor, but not if pulled from the OpenPKG repo)? Rgds, -ar >> 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 ______________________________________________________________________ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
