Re: openldap-2.1.16: what happened to cache.c?

["Kurt D. Zeilenga" <Kurt@OpenLDAP.org>]

> That depends on the definition of broken.

I consider any application which used the caching code to be
experimental as the caching code itself was experimental.
I consider any shipped application which expected the
pre-installed LDAP libraries to have been built with
--enable-cache to be broken.  --enable-cache defaulted to no.

While considering options, I think its important to do so
in the context of "experimental" code.   There are many
reasons why we label code as "experimental".  One reason is
warn that the code is likely to change in incompatible ways
between patch releases (including outright removal).  Another
is to warn that the code is likely broken.  Both of these
reasons and others apply here.

So, on the surface, one could argue that there is nothing
wrong with the outright removal of the code, it was
"experimental" after all.  However, given that the code was
present in library for quite some time and other factors,
I think it fair to consider options.

>a) Reintroduce the missing functions.
>b) Bump the soname.

>Please consider doing either (a) or (b) as the upstream entity.

Well, as I noted before, option (b) is problematic as that
would require applications which avoided the experimental
code to be rebuilt in order pick up important bug fixes
to non-experimental code.

And I think (a) is bad as code is broken and, to date, no
one has demonstrated any desire to fix the broken code.  (If
someone actually provided patches which fix the broken code,
then (a) would obviously be reasonable option.)

So, I'd suggest another option, include the shell functions
in the next 2.1 "incremental" release (but not 2.2, our next
"full" release) which were previously provided when caching
was not enabled.  This will resolve the linking issues without
reintroducing broken code, but does nothing to fix the broken
applications which expected caching to be enabled by default.

Kurt