[Pkg-openldap-devel] DEBIAN / UBUNTU OPENLDAP WILL NOT BUILD FROM SOURCE

[Ryan Tandy]

On Sun, May 22, 2016 at 09:14:16PM -0500, GI Joe wrote:
>---->>>[OK. Why? Is this to work around the contrib modules (specifically
>smbk5pwd) being set up to build with gnutls, while you're building with
>openssl?]
>
>Just testing...  as I was saying... it appears that the problems originate
>around all of that gssapi/samba stuff inserted circa 2009.   IMHO, It
>should still be able to compile, test, install properly no matter what
>libraries are finally linked.  (Try Redhat/Centos)

It does, for the components that are integrated in the autoconf build 
system, but the contrib modules are driven just by simple Makefiles, so 
do need some tweaking to ensure the proper flags are set.

>---->>>[(I was expecting a 'dch --local', or some other edit to
>debian/changelog, at this point, to distinguish your package from the
>archive version...)]
>
>Not yet.  Don't need to since I'm doing this as prep work before rolling
>out a 'final edition'.  Gotta be able to install and run it, first.  THEN
>build debs.

OK.

>---->>>[dh binary --with autoreconf
>--builddirectory=/.../openldap-2.4.42+dfsg/debian/build
>--parallel]
>
>Same thing.  dh executes to install target on "binary."  Builddirectory is
>resolved in debian/rules as the same thing at line 34...
>      builddir        := $(CURDIR)/debian/build

Not the same, trivially demonstrated:

dh binary

executes ./configure in the current directory, creating ./config.log.

dh binary --builddirectory=$(pwd)/debian/build

cd's into debian/build and executes ../../configure, creating 
debian/build/config.log.

And that does matter, as evidenced by your earlier quotes of things 
failing to find debian/build/libtool.

>Autoreconf usually unnecessary too when working with a virgin source tree
>or after a clean.

Yes, if we were building unmodified upstream sources: but in this case, 
you're missing out on changes made to configure.in by any Debian 
patches, of which there are several. Notably, some of the patches change 
or add other functionality _and_ change the build system to make it all 
work; so if you still have those packages included but you're not doing 
autoreconf, then yes, it's quite likely to break.

>---->>>[ Missing '--with autoreconf' might explain why you find yourself
>having to edit configure.in, while missing --builddirectory would explain
>the error about missing libtool I remarked on earlier. ]
>
>Not.  The vars were undefined in [context].  (Yes, I realize that's kinda
>vague... but, I went thru that hours ago)   See below.
>....
>
>fakeroot dpkg-buildpackage comes after I know this thing is going to
>install and execute and pass a couple hundred tests.

For faster iterations during development:

export DEB_BUILD_OPTIONS=nocheck

>---->>> 'dpkg-buildpackage -us -uc -b' does succeed for me, though, with no
>changes at all to the package. So maybe try using that instead?]
>
>Try running an ldapsearch -ZZ resulting in TLS 1.2 from Debian/GnuTLS to
>about 2000 other openldap servers running on Redhat or CentOS and you'll
>understand pretty quick.  Try adding a few more overlays and backends, too.

I don't understand how this is related to the dpkg-buildpackage 
suggestion, sorry.

I said "with no changes to the package" because that's how I'm testing 
it. I'd make sure you're calling the right commands to build the source 
unmodified first, then change GnuTLS to OpenSSL. I wouldn't expect 
further changes to be necessary.

>(BELOW:  After my changes)
>
>build/top.mk:VERSION_OPTION = @VERSION_OPTION@
>      <<<<-------------------------------

Looks like the VERSION_OPTION stuff is related to 
debian/patches/libldap-symbol-versions, which touches... configure.in. 
So yes, I'd expect to run into breakage with that patch applied but not 
running autoreconf.

And your GSSAPI_LIBS problem probably has two parts... the first is also 
autoreconf-related (since the gssapi patch also modifies the build 
system), and the second is fixed by running dpkg-buildpackage instead of 
debian/rules directly, which _shouldn't_ be necessary, but apparently is 
with the current xenial package. Next time I touch the Ubuntu package 
I'll look into that and try to fix it.