[Pkg-samba-maint] Bug#1021371: gnome-control-center doesn't start, saying libsamdb-common.so.0 requires version `LDB_2.2.4'

[Michael Tokarev]

07.10.2022 18:53, Simon McVittie wrote:
> On Fri, 07 Oct 2022 at 18:08:41 +0300, Michael Tokarev wrote:
>> 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.
> 
> I'm not sure that's completely accurate? ldb-tools, python3-ldb,
> python3-samba, samba, samba-libs, etc. also depend on libldb2 (perhaps
> with more -Wl,--as-needed they wouldn't, I haven't looked at whether they
> actually reference symbols from libldb2).

What I mean is that most of these only use a few common entry points of
libldb which does not change much and for which symvers mechanism provides
good results. Except of particular situation with this very version at hand.

> Outside the samba source package, several binaries from src:sssd also
> have dependencies on libldb2, although again I haven't checked whether
> they actually reference individual symbols or whether they just have an
> unnecessary DT_NEEDED entry.

sssd is one more package which uses libldb "heavily".

The problem here and with samba-dsdb-modules is that both provides *plugins*
for libldb, and we don't have a mechanism similar to symvers for plugins.

>> 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.



> The reason I like using debian/shlibs.local for this, instead of
> explicitly writing out "libldb2 (= ${binary:Version})" in d/control,
> is that it's automatic: every time one of your binary packages picks up
> a dependency on libldb2 from ${shlibs:Depends}, it will *automatically*
> be a strictly versioned dependency. Even if you've split libraries between
> binary packages in a way that didn't really match what you intended (like
> if you didn't intend for samba-libs to depend on libldb2 at all), the
> failure mode is that there's a strict dependency (possibly unnecessary,
> but never wrong) rather than a loosely-versioned dependency (which can
> result in making mismatches possible).

Only particular packages needs strict deps, there's no need to depend
on exact version for other packages.

> I make as many mistakes as anyone else, so I like to use tools that will
> prevent unintended situations from happening :-)
> 
>> 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)
> 
> If both the packages are Architecture: any, then I don't think there's
> a particularly good reason to use this version-range style with (>=)
> and (<<) - you might as well just eliminate all flexibility by using
> (= ${binary:Version}), since libldb2:amd64 (= x) is going to be available
> if and only if samba-dsdb-modules:amd64 (= x) is also available. After all,
> they both came out from the same sbuild run and got installed in the
> archive by the same .changes file...
> 
> Or if you're doing tricky things with different versions for different
> binary packages, as with libldb2, it seems better to represent that as
> an exact dependency on "the version of libldb2 that was produced by this
> exact build of src:samba".

This is only needed for samba-dsdb-modules (and in parts for sssd - it
uses only a subset of libldb plugins functionality which seems to be
mroe or less stable).

And once again, I just moved libldb to build from samba source, before
it used its own source package.

> On Fri, 07 Oct 2022 at 18:19:34 +0300, Michael Tokarev wrote:
>> With debian bullseye version of samba things are even more interesting.
>> This is because ldb-2.2.4 has never ever been released to begin with.
>> It was a bugfix within 4.13 series of samba - backported to 4.13 samba
>> long after 4.13 has been end-of-lined.  The actual symbols in ldb are
>> present in 4.16 (ldb 2.5.x), but not 2.2.4 version.
>>
>> And actually it brings a new question.  When we upgrade a library in a
>> stable debian release, and this upgrade brings new symbol version, but
>> already existing version of this library in testing does not have this
>> version.. what do do?  Should we omit the version bump in the stable
>> series?
> 
> This is quite a weird situation to be in, and I would tend to say that
> upstreams that track their public ABIs this carefully (or their downstream
> maintainers, if it was Debian that did this backport) should generally
> not be backporting new ABI to stable-branches at all. Several of the
> upstreams I follow have a fairly strict policy of stable-branches not
> adding new ABI *at all*, not even for bug fixes. However, I realise that's
> not necessarily always possible.

Existing ABI in the library did not let a significant security issue to
be fixed, - new symbol had to be introduced (actually several), and samba
switched to use these new symbols. And those new symbols has been backported
to old samba version by the upstream. Once again, in bullseye, libldb is
built by its own source package.

Maybe we did it wrong and we should not introduced 2.2.4 version (it is
easy by just removing the *version* symbol, - and sure, our symvers
mechanism would kick in. But the question is what to do now with the
*current* issue - probably I should include this single *version* symbol
in the bookwork samba.

> If samba upstream are effectively treating some new symbols as being
> essentially private to the source package, then the other thing you
> could do is to flag them as such in debian/*.symbols. This is a bit
> annoying to do: the best way I've found is to have a .symbols.in file,
> and preprocess it to create the actual symbols file to be consumed by
> dpkg-shlibdeps and dpkg-makeshlibs.

They're not private, not at all.

It is just this very *version* symbol which is not present in a
more recent version of the library (and actually is not present anywhere
else except of this particular bullseye samba release - not even on other
linux distributions).

*sigh*.

The more I think about this, the more it looks to me that I should include
this very LDB_2.2.4 *version* symbol into the bookworm release.

/mjt