[Pkg-samba-maint] ldb modules dir and <ldb.h> placement: is ldb samba-specific or not?

[Michael Tokarev]

11.04.2022 00:04, Andrew Bartlett wrote:
..
>> Maybe we should drop this --with-modulesdir= from the samba
>> build rules?
> 
> The original intent was that Samba modules (the dsdb modules) would be
> separated from the 'normal' ldb modules.  But if you have them all in
> the same spot then you get all the Samba features (NTLM authentication
> etc) 'out of the box' for the ldb tools, but on the flip side you put
> our GPLv3 code into every user of libldb.

Mmm. Please note it is samba who builds/installs them that
when using supplied (vs already installed) ldb: both dsdb
modules and original ldb modules installs into the same
subdir, using the same config variable.

It is just so happens that for *debian*, while building
ldb from its own source, we used different value for
this config variable (and it ended up with an ugly
name of /usr/lib/$triple/ldb/modules/ldb/ - the last
part was - IMHO - wrong).

If the two needs to be separate, samba should have a way
to specify ldb modules directory separately from the
samba modules directory, or something like this.

Please note that samba-dsdb-modules has Enhances: libldb2,
too, so at my expectation it should be ready to use
the dsdb modules with ldb right after installing of
this package. Adding something arch-specific (ie,
different on every machine) to some variable before
doing that is really not a good idea.

Is it a problem - from the licensing PoV - that samba
dsdb mods are available for every user of libldb?

Another question of the same theme: how other ldb users -
such as sssd - should provide their own modules?
I don't know if the sssd module is useful for other
programs, maybe sssd should just add its private directory
to $LDB_MODULES_PATH (or what's the name of this variable)
before calling the ldb code. (And in this case it is okay
to add some arch-specific path in there since it is known
at build time).

> I tried to counsel for keeping the paths as they were, and I think that
> is still right - an original patch for this merge did most of the work
> by changing the value of 'standlone_ldb' in the wscript.

"Keeping the paths as they are" where? In samba (where they're
all in $libdir/ldb - both dsdb and ldb), or in debian, where
they WAS in $libdir/ldb/modules/ldb for ldb and in $libdir/samba/ldb
for samba?

Original patch by Mathieu Parent when merging ldb package
building into samba was this:

  https://salsa.debian.org/samba-team/samba/-/commit/901460b1e1bdbfa8b8db600856fc284478e6c365

(ldb import: LDB modulesdir is now /usr/lib/$arch/samba).
He did not change the ldb *modules* dir to be the one
as when ldb were built as standalone. He only changed
the internal-*library* dir.

Yes I'm aware about his other change (which I imported too) -
the one which allows ldb library to be built as external
lib from samba source, this one:

https://salsa.debian.org/samba-team/samba/-/commit/062627653d82c3ee5274737efcc6c79a704f50aa

> I am concerned that the 'private' version of these libs might have a
> strange ABI signature / version suffix also.  Please check.

This is not a problem at all, and this is actually about
something else: about the internal libs and the directory
where they're kept.  These are 2 separate configure paths,
   --libdir=/usr/lib/$arch/samba/ - where to put internal libs,
   --with-modulesdir=/usr/lib/$arch/samba - for modules.
These can be separate, we just bundle them together.  And
from there, each subsystem's module dir is a *subdir* of
the $modulesdir (hence it was /usr/lib/$arch/ldb/modules/ldb
before - with extra "/ldb" suffix which is always added).

..
>> A similar question (wrt the file placement) comes about ldb.h which
>> is moved from /usr/include/ldb.h to /usr/include/samba-4.0/ldb.h.
>> This is easier since all stuff is in pkg-config and it is picked up
>> automatically. But there, the question is a bit different:
>> is ldb.h specific to samba or is it actually not tied to samba?
>> If it is the latter, we can move this very include file back
>> into /usr/include where it goes when built from separate ldb
>> package.
> 
> I think things should stay where they were.  That is certainly what I
> would expect to be accepted upstream once this is demonstrated in
> Debian - we want the patches learnt here to go upstream.

For this to work, samba (and ldb) build system should have either
a few more options (like, for example --with-ldbmodulesdir separate
from --with-modulesdir, something similar for --includedir too, or
maybe ldb should put it include file into original --includedir
instead of that one plus samba's suffix). Or we have to add a
dirty fix after samba install procedure to move some files
around and perform some .pc files fixups, which is ofcourse
not good to push upstream.

> I hope this helps.

Is ldb supposed to be its own or is it a part of samba?

If it is not part of samba, it should stay separate and
build from its own source.

Thanks,

/mjt