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 > Python-LDAP-dev@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
------------------------------------------------------------------------------ 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 Python-LDAP-dev@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/python-ldap-dev
