Re: berkeley DB problems

[Andy Mayhew]

That would only work if you also changed the cfengine build to always be
statically linked against BerkeleyDB versus the current default dynamic
linking.  Which means you are still editing build configuration files.  So
might as well just fix the configs in the first place instead of adding a
kludge.

Anyway, version skew is a nasty problem.  I don't think anyone wants to have
the job of making sure the cfengine source tree always contains the current
cfengine-blessed version BerkeleyDB.  It should suffice that the software
requires a particular major rev and let the administrator determine which
minor rev best works in their environment.  You never know if SleepyCat
might break the build by accident for some environment.  I also doubt that
the FSF would really appreciate having GPL software tarballs include
non-GPL'd code.

It would seem a lot of the problems people have are related to the fact that
RedHat is inconsistent in how they lay out their directory structures.  If
that company could figure out how to follow some fairly simple conventions
and not make new ones up as they went along, a lot of people would be
happier in general.  <shrug> I realize that their excuse is they do "odd"
things so that you can have multiple versions of libraries and binaries on a
machine living happily.  But this seems to not work very well in practice,
unless you limit yourself to only ever using RedHat approved rpms.

I'm going to attempt to look at the configure.ac file in order to fix this
problem.  That would be the more proper remedy.

My sleep-deprived $0.02.
--Andy Mayhew <address@hidden>

On Sat, Apr 20, 2002 at 08:52:40AM -0400, Ted Zlatanov wrote:
> Considering the number of problems so far with the various locations
> of the Berkeley DB (which I've also experienced with Perl modules, but
> that's another story), why not just include the BDB version cfengine
> needs with cfengine?  The problem then becomes one of tracking the BDB
> releases and deciding when cfengine itself needs to include a newer
> release, but surely that's better (and more reliable) than trying to
> cope with every vendor's idea of where the BDB should live.
> 
> It's only a 2MB tarfile...  Seems like a small price to pay.
> 
> Ted