OK, here's another idea for the back-bdb/cache.c patch - if using BDB
4.2.52 it tries the alternate flag first. If it fails, it logs the
failure and reverts to running without the alternate flag. Or, we can
just let it fail and have slapd shutdown instead, and require people to
patch their BDB library.
Personally, I alway suggest to apply the currently available patches, and
I always deploy patched versions of slapd with db-4.2.52, but I wouldn't
agree with __requiring__ BerkeleyDB to be patched for a number of reasons,
including the fact that the patch actually isn't official, so customers
might prefer to live with an official db-4.2.52 as far as they're aware of
the limitations it implies. In fact, we can surely live without that
patch, provided we periodically shut the service down. In this case a
stock db-4.2.52 would perfectly fit every need without any patch.
I strongl agree with slapd trying to detect at compile/run-time if the
db-4.2.52 is pched or not, and with logging the result. We could have the
behavior you envisaged as the default (i.e. slapd refusing to run with a
non-patched db-4.2.52), with a switch that allows the conscious admin to
work it around (i.e. some "live-with-unpatched-db" config parameter).