[Git][openldap-team/openldap] Pushed new branch external-lmdb

[Quanah Gibson-Mount]

--On Sunday, January 19, 2025 1:54 PM +0300 Michael Tokarev 
<mjt at tls.msk.ru> wrote:

> 19.01.2025 00:30, Quanah Gibson-Mount wrote:
>> --On Saturday, January 18, 2025 11:48 AM +0000 "Michael Tokarev (@mjt)"
>> <gitlab at salsa.debian.org> wrote:
>>>
>>> Michael Tokarev pushed new branch external-lmdb at Debian OpenLDAP
>>
>> I'm not exactly sure what this branch is for, but I would note that
>> OpenLDAP *only* supports the version of LMDB that's shipped with a given
>> release.   If the idea for this branch is to link OpenLDAP to a separate
>> LMDB package, I would advise against it.
>
> Hi!
>
> Thank you for the comments, this is much appreciated.

> We've quite old 2.5 version of OpenLDAP in debian stable (2.5.13),
> and I was thinking about updating it - for this, I studied all the
> changes made in OpenLDAP, including LMDB, between 2.5.13 and current
> 2.5.19 - yes, some changes in LMDB are definitely required, but not
> all of them.  And it stays backwards compatible, which is also a
> good sign of a mature, well-managed software.  So a proper versioned
> constraint (liblmdb >= 0.9.33 for current slapd = 2.5.19) seems to
> be all what's needed.
>
> Do you have other testing besides the built-in testsuite (which is
> also run during package build in debian)?
>
> I'm definitely not about "forcing" things here, I'm really curious for
> your reasons.

Hi Michael,

I brought this thread up with Howard Chu, the primary OpenLDAP & LMDB 
developer. This is what he notes as to why this should not be done:


LMDB is built as intrinsic part of back-mdb in OpenLDAP, it isn't used as a 
library to be linked against.  LMDB itself isn't meant to be built as a 
system-wide library to be used by multiple packages. It has a bunch of 
compile-time options. It's meant to be built specifically for an app and 
embedded into it.

LMDB is designed with performance as priority #1, not for compatibility. 
That's why its files are architecture-specific.

So it is normal and expected that different apps use different versions 
that may produce mutually incompatible DB files.

In OpenLDAP we don't check LMDB feature flags, because we "know" that we're 
building against the code in our source tree. Breaking that assumption 
invites possible breakages in build time or run time.

Of course we're not masochists and we've tried to maintain forward 
compatibility as much as possible...

But backward compatibility isn't a given. So far it's been maintained, but 
will certainly break from 0.9 to 1.0.

Anyway, it's only 64KB of object code. There's nothing gained from building 
it as a library. Building it as a dynamic shared library bloats it by more 
than 10%, and also decreases its performance.




Regards,
Quanah