Re: sasl version mismatch: 2.1.15 vs 2.1.17

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

On Tue, Dec 09, 2003 at 11:24:22AM -0800, Howard Chu wrote:
> > See above, it's not about mixing different headers and
> > libraries, that's stupid.
> 
> Yes. And it's what plenty of people try to do, all the time. It's exactly
> what you're trying to do by attempting to use a Cryus 2.1.15 library on an

It's not, I'm not mixing 2.1.x headers with 2.1.y libraries.

> executable that was compiled against 2.1.17. When you compile against one set
> of headers, those header definitions are effectively embedded into the
> resulting binary. When you run the code with a different library version,
> then you have the exact same problems as any other library/header mismatch.

Important headers and symbols shouldn't just get redefined at will between 
minor releases. And if they are, the soname should be bumped. This is project 
dependent, however, not all respect or care about this.

> Wrong. If you compile OpenLDAP with Cyrus SASL 2.1.15 it will not complain
> when you run with version 2.1.17 libraries. Increasing values of 'n' (2.1.n)
> are always allowed.

Ah, this is better. I can change the rpm requirements from:

Requires: cyrus-sasl = version-which-is-here-at-build-time (bad)

to

Requires: cyrus-sasl >= version-which-is-here-at-build-time (less bad)

If possible, this would be better, though:
Requires: cyrus-sasl >= version-which-is-known-to-work

> > Does cyrus sasl have
> > a history of making such incompatible changes?
> 
> API compatibility is only part of the story. The other part is simple bug
> fixing. We tend to be on the bleeding edge of Cyrus SASL's feature set. When
> a feature we rely on is broken in the SASL library, and it gets fixed in a
> subsequent release, we require that revision or newer at configure time. If

This makes perfect sense, I'm not against that. I also note that openldap
2.1.25 currently requires only cyrus-sasl-2.1.3 or higher.

> the library you run with is older than the one we found at configure/build
> time, we complain, because most likely that older code is broken.

This is different.

In this case I think the check should be against that specific version which fixes the problem,
and not against the version with which the app was built.

It's obvious now the project has been bitten before by such problems, and then the
version check was inserted. Fine with me. I was just trying to raise a point
that this could perhaps introduce unecessary administration overhead. I'll stick with the
cyrus-sasl >= version-which-is-here-at-build-time + soname requirements.