apr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Disconnecting -lldap from utilizing apr-util
Date Fri, 23 May 2008 20:13:41 GMT
Amazing how consistently someone's vetoes only arrive after proposals
have been offered for over a week and developers had already invested
the time to author the solution they originally proposed.

Simply amazing.


On May 15, 2008 William A. Rowe, Jr. wrote:
> What is interesting is that a patched apr-1.3.x remains binary compatible.
> Simply ./configuring --enable-dbd-dso (really should be --enable-dsos) in
> combination with --with-ldap will toggle the behavior.
> What breaks in terms of ***build*** behavior is that it becomes the user's
> responsibility to add the result of `apu-1-config --ldap-libs` to the app's
> ld bindings.  Otherwise, the non-ldap-consuming app won't have a direct
> binding to libldap.  Which IMHO is how it always should be.
> The question is - is this a permitted change in 1.3.0?  I believe it is, we
> should not have been in the business of providing libraries in the manner
> that happened for ldap.  The other accessors, expat, iconv, etc don't carry
> this sort of communicative property for our util users.  In short, it was
> a failed contract that should be harmonized without disrupting our users
> too terribly.  The --ldap-libs query lets them resume.
> But this is not far enough, and only phase 1 of a patch.  The complete
> patch should abstract the rest of the ldap provider such that they do not
> need to bind to -lldap in the first place.  If this is not the goal, I'd
> argue that this ldap binding really wasn't appropriate in the first place.
> [Of course, that's an argument for 2.0 sans ldap and not a solution for 1.3
> next release ;-]  But I didn't want to hold up discussing a patch just to
> add stubs to apr_ldap_err2string etc etc.
> I also didn't hold up to add the parsing of LD_LIBRARY_PATH etc to find the
> libraries (ldap, and dbd as well).  That's something to discuss as well, 
> and
> again not a reason to hold up this patch.
> Folks had hoped that httpd-2.2.9 would be compatible with either 1.2 or 1.3
> apr flavors.  We can get closer by improving the config.m4 patches, e.g.
> MOD_AUTHNZ_LDAP_LDADD="`$apu_config --ldap-libs`"
> becomes
> MOD_AUTHNZ_LDAP_LDADD="`$apu_config --ldap-libs`" \
> meaning that when --ldap-libs is unrecognized, we surrender to the complete
> libs exposed by apr-util-1.2.x.  But this would only be a provisional 
> change
> for the lifespan of httpd-2.2.x until it absolutely requires 1.3.0.
> This does create a hardship for ldap users of apr-util _ldap API, but with
> consideration given to the many, many applications of apr-util which don't
> utilize the _ldap API, this change seems very appropriate to me.  The note
> about --ldap-libs can be prominently listed as the first entry in CHANGES.
> Comments, feedback or questions?
> Bill

View raw message