Hi Helmut,
On Wed, Aug 26, 2015 at 09:26:26PM +0200, Helmut Grohne wrote:
I think that when adding a stage one should look further than just the
immediate cycle. This is the main reason that prevented me from
submitting a stage for openldap: I was lacking assurance that I was
doing it correctly.
Given further testing I now have somewhat more confidence, so let me
propose a very different stage1: --disable-slapd
Why does this make sense? This stage builds way less than the stage
proposed by Daniel. It also drops heimdal, but it also drops
cyrus-sasl2. Keep in mind that cyrus-sasl2 and openldap do have a direct
cycle that needs to be addressed in either cyrus-sasl2 or openldap. So
rather than add yet another stage to drop libsasl2-dev or add a stage to
cyrus-sasl2 dropping libldap2-dev, I therefore think that openldap's
stage1 should also drop the libsasl2-dev dependency. Turns out the
easiest way to do so is just not building the server.
I don't have any objection to building stage1 without slapd, if that
helps. Most of the Build-Depends are only needed for slapd. For just the
libraries and clients, I'd say we only need debhelper, dh-autoreconf,
gnutls-dev, libsasl2-dev, and groff. Maybe a couple more, not certain.
(Hmm.... I actually don't even know what ncurses-dev is used for...)
I'm a bit more concerned about dropping libsasl2-dev, as this disables
SASL functionality in libldap-2.4-2 and ldap-utils. Functions such as
ldap_sasl_bind are still exported, but only return LDAP_NOT_SUPPORTED.
This also makes dpkg-gensymbols complain, as a few internal/private
SASL-related symbols disappear.
