Control: tag -1 + confirmed
07.10.2022 11:38, Simon McVittie wrote:
...
# smbclient --help
smbclient: /usr/lib/x86_64-linux-gnu/libldb.so.2: version `LDB_2.2.4' not found
(required by /usr/lib/x86_64-linux-gnu/samba/libsamdb-common.so.0)
Workaround: also upgrade samba-libs to the version from testing, or fully
upgrade to testing.
Removing the symver LDB_2.2.4 from libldb.so.2 was an ABI break, so libldb2
should have versioned Breaks against dependent packages that use the old
symver. It looks as though only the samba and maybe sssd source packages
will be affected by this.
I talked about this with upstream samba. It is their decision to break old
stuff like this, by dropping intermediate library versions without actually
changing any functions/symbols. I don't know why this is done like that,
from my PoV it is plain wrong.
When I packaged 4.17 version (currently in experimental), I created a patch
which adds missing intermediate versions (added during maintenance of 4.16
series) to 4.17, but later on dropped it. It will be the same with 4.16->
4.17 upgrade. See
https://salsa.debian.org/samba-team/samba/-/commit/363ec9c9cf107536b94bfd0d5bd623644413b165
In debian samba package, there's a strict versioned dependency of libldb2
for samba package - actually samba-dsdb-modules - the only package which
actually *uses* libldb. For a bullseye version of samba-dsdb-modules
package, the dependency is
libldb2 (<< 2:2.2.4~), libldb2 (>= 2:2.2.3-2~deb11u2~)
(so it conflicts even with next minor version of libldb2).
But it looks like other samba packages does have libldb2 dependency.
It looks like I need to take a look at how libldb2 is used by samba-libs,
maybe some libs should be moved between packages.
Also, when a single source package builds multiple libraries, it's usually
a lot more robust if the dependencies between those libraries are strict
(libfoo Depends: libbar (= ${binary:Version}) so that users are forced
to upgrade either everything or nothing from that source package. This
The only real user of libldb2 in samba is samba-dsdb-modules. And exactly
due to this reason I switched from the ugly "between" version like I
demonstrated above to exact version. libldb2 builds from samba package
since bookworm version (4.16), in bullseye libldb was in its own package.
is because the upstream developer will never have tested with mismatched
versions, and code in the same source package often uses private/internal
interfaces that are not formally part of the API/ABI, or relies on
internal implementation details that might change in a newer version.
I weren't aware that libldb2 is linked to from samba-libs. Now I do, and
ofc I'll take care of this. Either by adding countless patches adding
missing versions which upstream refuses to add for some unknown reason
like I initially did for 4.17 version, or by rearranging libraries into
different packages so that libldb isn't used by samba-libs, or maybe
upstream will do their part and add those versions itself, I dunno.
Thanks,
/mjt
