On Wed, Aug 28, 2024 at 11:33:15AM +0200, Graham Leggett wrote: > On 21 Aug 2024, at 16:11, Joe Orton <jor...@redhat.com> wrote: > > > On Mon, Aug 19, 2024 at 07:33:07AM -0000, minf...@apache.org wrote: > >> Author: minfrin > >> Date: Mon Aug 19 07:33:06 2024 > >> New Revision: 1920017 > >> > >> URL: http://svn.apache.org/viewvc?rev=1920017&view=rev > >> Log: > >> apr_ldap: Make the sasl callback disappear when OpenLDAP is not > >> used. > > > > I think this code should also not be built if the <sasl.h> checks both > > failed. That would avoid the httpd build failures on systems where > > previously this code built fine (maybe that's Debian/Ubuntu only but > > regardless, it's a regression). > > I sent an email addressing this, from what I can see this is a bug in Debian > packaging. > > If you use OpenLDAP's ldap_sasl_interactive_bind() function, you are > depending on sasl.h. Debian's OpenLDAP dev package doesn't depend on > the SASL library's dev package, missing package on the build server, > thus this problem. > > Having said that, some archaeology shows that > ldap_sasl_interactive_bind() was added to OpenLDAP 14 years ago. What > we should do is make the whole new API APR_ENOTIMPL if > ldap_sasl_interactive_bind and sasl is missing. New apr-util + ancient > OpenLDAP should be rare, but it costs nothing to do this.
That definitely makes sense to me, but perhaps the Debian maintainers will argue it's an optional dependency, which is also true & reasonable - you *can* use the LDAP API without caring about the SASL API - as apr-util did previously. So I think the build should not fail in cases where it previously worked. > Is there a way to get some CI set up for apr/apr-util? That will > prevent us getting all the way to httpd before we find a problem. APR has Github actions set up already, but there was no LDAP coverage added with the new LDAP API in trunk so it wasn't getting tested. Branches for APR-util do not have CI but it would be possible to add. Regards, Joe
