(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. ------------------------------------------------------------------------------ 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 [email protected] https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
