Dear Maintainer,

Installing packages which depend on libldap2 with
--no-install-recommends will not install the libldap-common package.

This may result in unexpected behaviors when libldap2 code paths are
triggered due to a missing reference to the trusted CAs certificates,
which is defined by the configuration file shipped in libldap-common.

Since the dak bug affects several other packages, this should, ideally,
be fixed in dak.

This was originally reported in Ubuntu [3] due to a bug found after a
user installed the php-ldap package.

A fix proposal was forwarded to salsa in [4].

[1] https://salsa.debian.org/openldap-team/openldap/-/commit/567d8d6d7e36717540d9bced79c45c788ab5be03
[2] bugs.debian.org/cgi-bin/bugreport.cgi?bug=915948
[3] https://bugs.launchpad.net/ubuntu/+source/php-defaults/+bug/2063161
[4] https://salsa.debian.org/openldap-team/openldap/-/merge_requests/9

Hello Athos,

Yes. It's not a great user experience, and while I believe Recommends is
technically Policy-compliant, I agree Depends would be preferable.

I am marking this bug as blocked by the dak bug for visibility. Due to
the severe consequences when the issue occurs (many packages become
BD-Uninstallable due to transitive build-dependencies on libldap,
requiring a manual bootstrap upload of openldap to resolve), I cannot
accept the patch until _after_ dak has been fixed.

thanks,
Ryan

Thanks for the quick reply here, Ryan!

I understand the pain there. How often did the issue occur back then
when the libldap-common was in Depends?

It's a few years ago now, so I don't remember exactly.

Initially it was a tightly versioned Depends. That caused a lot of
trouble when combined with some flaky tests that we had at the time.
There was a couple of uploads where my sponsor ended up doing a lot of
binary uploads to unstick things.

Switching to unversioned Depends improved things but didn't solve it
completely. I can't remember whether any binary uploads were done -
maybe none. I did one sourceful bootstrap upload, which you can still
see in the changelog.

Once I understood the issue, I tried to mitigate it by uploading when
the buildds were quiet, hoping the amd64 and arch:all builds would both
start before the next dinstall. That was mostly successful: if the
builds _finished_ at different times, the package might vanish
temporarily, but as long as they both _started_ in time, it would be ok
after they finished and published.

The Recommends workaround has made uploading a LOT less stressful, not
to mention safer for binNMUs etc.

Dear maintainers,

first of all - thanks for maintaining this packet.

I would like to ask if there is any update on this bug.

We ran into this while troubleshooting a connection error during ldapsearch (from ldap-utils).
Essentially, any connection over LDAPS will fail with an unspecific error message if libldap-common is not installed.
Maybe at least ldap-utils should depend on libldap-common?

Thanks!

As always, I have to point out that Recommends are meant to be installed
unless you know that you truly don't need them; and that libldap does
work without libldap-common, as long as you configure the CA cert
setting yourself.

Anyway, in trixie and later this should be a non-issue. libldap now uses
the system CA certs by default, so the configuration that used to be
shipped in libldap-common is no longer needed.