Minimum version of OpenLDAP libs for python-ldap 2.4.x?

[Michael Ströder]

(Cc:-ed python-ldap-dev again)

Chris Dukes wrote:
> On Fri, Mar 04, 2011 at 07:45:15PM +0100, Michael Ströder wrote:
>> Again it's time to think about the minimum required version of OpenLDAP libs
>> to be used for building upcoming python-ldap 2.4.0. I'd vote for strictly
>> requiring a fairly recent version in the OpenLDAP 2.4.x release series. I know
>> that this rules out using packages provided in RHEL 5 or similar old
>> enterprise Linux distros.
>>
>> I'm asking because support for the assertion control was fixed/extended in
>> HEAD but it relies on OpenLDAP 2.4.11+. Currently it's hidden behind a
>> #ifdef LIBLDAP_HAS_ASSERTION_CONTROL_FUNC
>> but I generally don't like to have features which are there or not there
>> depending on the build.
> 
> No newer than what initially shipped with RHEL 6.0

RHEL 6 is fairly new.

> I deal with production systems and boneheaded management that wants 
> worthless support contracts for items like the OS.
> For the ones that don't ship OpenLDAP, requiring a new version isn't much of
> an issue.  However, for the ones that do ship OpenLDAP it's the choice between
> the support nightmare of "That part isn't at a supported version" when
> something unrelated breaks and the support nightmare of maintaining a couple
> custom chroots with a horribly de-skilled set of admins.

Believe me I know all this quite well from various discussion with my customer
and their admins. But strictly speaking in support terms you would not even be
allowed to install a self-compiled version of python-ldap. And Red Hat won't
provide an update of python-ldap 2.4.x for RHEL 6.0 anyway.

> It's more work, and more parts to break, but I'd suggest tinkering around to
> see if the version # can be pulled from the OpenLDAP library and have some
> python class implementations that depend on the version to change whether
> they return an supported version exception.

This could be done and in some parts it's already done in python-ldap and my
web2ldap. But...

Normally dependencies are:
pkg A ver. x depends on pkg B ver. y

With you suggestion above this gets even worse:
pkg A ver. x depends on pkg B ver. y built with options m, n, etc.

So imagine how to write that in a decent operational manual.

Or the whole chain of components treat everything optionally which is a
nightmare to maintain in code and makes users quite unhappy...

Ciao, Michael.