Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <48372575.8070100@rowe-clan.net>
Date: Fri, 23 May 2008 15:13:41 -0500
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 2.0.0.14 (X11/20080501)
MIME-Version: 1.0
To: APR Developer List <dev@apr.apache.org>
Subject: Re: Disconnecting -lldap from utilizing apr-util
References: <482CB65C.1000306@rowe-clan.net>
In-Reply-To: <482CB65C.1000306@rowe-clan.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.

Bill

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`" \
>     || MOD_AUTHNZ_LDAP_LDADD=""
> 
> 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