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