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

[Simon McVittie]

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

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.

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

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

I think the only times it's helpful to use (>=), (<<) is when you're doing
a dependency between Architecture: any and Architecture: all packages
(in which case you need to allow a bit of fuzz in order to accomodate
binNMUs), or when you're doing a dependency between different source
packages (for instance different GNOME modules wanting to be at a matching
GNOME major version, but willing to tolerate smaller differences between
different point releases).

One place where (= ${binary:Version}) can be a problem is if you have a
transitional package: for those, it's better to use (>= ${binary:Version})
with no upper bound, so that an old transitional package can remain
installed if necessary, even after it has been dropped from the latest
version of its 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.

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.

For instance, take a look at debian/libdbus-1-3.symbols.in in src:dbus.
For the public symbols, it generates a dependency on the version that
introduced the symbol. For the private symbols, it has a second dependency
template which generates a lockstep dependency, so that any user of dbus'
private symbols (which by definition should only be other binary packages
from within src:dbus) depends on the exact version it was compiled against.
That might be a useful technique for samba as well?

Of course, if the extra symbols are also used by external packages like
sssd, then there's probably no alternative to using versioned Depends/Breaks
to force everything to be on the same side of the transition. I hope that's
not the case here.

    smcv