Control: reassign -1 libldb2 2:2.5.2+samba4.16.5-1
Control: severity -1 serious
On Thu, 06 Oct 2022 at 22:18:46 +0000, Albert Nash wrote:
> The control center starts neither from gnome (Alt+F1 > Settings) nor from an
> xterm. In the last case, we get some (hopefully, useful) output:
>
> $ gnome-control-center
>
> gnome-control-center: /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)
...
> The system is Debian stable 11 “bullseye” with a few
> updated packages from Debian testing.
Debian tries to support partial upgrades on a best-effort basis, but
they are often not completely supportable, because the number of possible
combinations of package versions is just too high.
In this case, it looks like you have probably upgraded libldb2 from bullseye
to testing without also upgrading samba-libs. The dependencies allow this,
so it should in principle be OK, but in fact libldb2 has an incompatible
change to its versioned symbols that means it is not.
I can reproduce this without using gnome-control-center, by using
smbclient, so this is not a gnome-control-center bug. In a minimal
bullseye container:
# apt install --no-install-recommends smbclient nano
# smbclient --help # it works
# nano /etc/apt/sources.list # and add bookworm apt sources
# apt install --no-install-recommends libldb2 # upgrades libldb2
# does not upgrade samba-libs
# 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.
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
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.
The easiest way to achieve those strict dependencies is usually to add a
debian/shlibs.local that lists all the libraries built by this source
package and makes them generate a strict dependency on the corresponding
package. For instance, here's the one from pango1.0:
https://salsa.debian.org/gnome-team/pango/-/blob/debian/master/debian/shlibs.local
Thanks,
smcv
