Re: sasl version mismatch: 2.1.15 vs 2.1.17

[Andreas <andreas@conectiva.com.br>]

On Tue, Dec 09, 2003 at 10:48:32AM -0800, Howard Chu wrote:
> It would seem that both questions are for the SASL folks.
> 
> The point is that the code you're running with is not the code you compiled
> against, and any number of APIs and data structures *may* have changed.

That's what a thing called "library soname" is for. When it changes, the API
changed. That's how it should be used, anyway.

> Whether they *have* changed or not is irrelevant, we're not going to sift
> thru every line of 3rd party code to discover that. It is usually safe to run

So the question is whether openldap developers trust cyrus sasl developers to
not make incompatible changes between library releases with the same soname.
It seems this trust is not there. Unfortunately there are plenty examples of
cases where incompatible API changes were made within the same soname. Openldap
has done it as well when it removed some caching code and broke applications
which relied on it being there between minor library upgrades. Openssl is
a champion regarding this, so much in fact that their soname now uses the
whole version number and no longer just the major one.

> code compiled with older headers against a newer version of a library. It is

It's not about headers version X and library version Y. It's about requiring
the same exact specific version used for the compilation.

> seldom safe to run code compiled with newer headers against an older version
> of that library. Call that pedantic if you like, I think it's common sense.

See above, it's not about mixing different headers and libraries, that's stupid.
It's about the specific version requirement. This means that whenever sasl is
upgraded, even a minor upgrade (like 2.1.n -> 2.1.n+1), openldap will have to 
be recompiled and reinstalled. Is this really necessary? Does cyrus sasl have
a history of making such incompatible changes?