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

HI!

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.

The above is only one example. I could think of more features to be added. And
I think the feature set of python-ldap 2.4.0 should be as independent from the
build options as possible.

Ciao, Michael.

(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.

On 03/04/2011 12:17 PM, Michael Ströder wrote:
> (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.
I am in favor of having python-ldap 2.4 support openldap 2.4
>> No newer than what initially shipped with RHEL 6.0
> RHEL 6 is fairly new.
RHEL 6 has openldap 2.4.19 - RHEL 6.1 will have openldap 2.4.23 + many 
of the patches that ended up in .24.
>> 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 would be difficult, but not entirely out of the question.  There are 
several new projects in RHEL6 like ipa that use python-ldap pretty heavily.
>> 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.
>
> ------------------------------------------------------------------------------
> What You Don't Know About Data Connectivity CAN Hurt You
> This paper provides an overview of data connectivity, details
> its effect on application quality, and explores various alternative
> solutions. http://p.sf.net/sfu/progress-d2d
> _______________________________________________
> Python-LDAP-dev mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-ldap-dev

On Mar 5, 2011, at 2:45 AM, 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.

Does it mean py-ldap-2.4.0 won't support OpenLDAP-2.3.x series?

Debian 5, RHEL/CentOS 5 ships OpenLDAP-2.3.x.

I don't think it's a good strategy to force sys admin to compile/install openldap-2.4 on  production server, if they want to update openldap, they have to compile again and again.

Zhang Huangbin wrote:
> 
> On Mar 5, 2011, at 2:45 AM, 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.
> 
> Does it mean py-ldap-2.4.0 won't support OpenLDAP-2.3.x series?

Yes.

> Debian 5, RHEL/CentOS 5 ships OpenLDAP-2.3.x.

Well, python-ldap 2.3.x will still be around. So if you're using this distros
you have to stick with python-ldap 2.3.x which IMHO is sufficient to run the
applications implemented on top of python-ldap so far. Applications requiring
new features will need new python-ldap and therefore newer OpenLDAP libs. This
is a common practice.

> I don't think it's a good strategy to force sys admin to compile/install
> openldap-2.4 on  production server, if they want to update openldap, they
> have to compile again and again.

Well, as said: If you don't want to compile on systems you won't install new
python-ldap 2.4 anyway on these old systems.

Ciao, Michael.