[dm-devel] multipath-tools: Debian patches

[Chris Hofstaedtler]

* Martin Wilck <mwilck at suse.com> [230606 21:40]:
> On Tue, 2023-06-06 at 18:48 +0200, Chris Hofstaedtler wrote:
[..]
> > > If Chris has followed the upstream discussion, he is probably aware
> > > that we do care about the ABI. We don't keep the libmultipath ABI
> > > stable, but track it using ABI versioning.
> > 
> > I was only vaguely aware of the changes in the <lib>.version files,
> > and that all .so files are ".so.0".
> > From a quick glance it looks like libmultipath.so.0 from 0.9.4
> > exports a lot of symbols versioned @LIBMULTIPATH_17.0.0, but f.e.
> > none versioned @LIBMULTIPATH_15.0.0, but the soname didn't change.
> 
> Maybe Debian enforces additional policies I'm unaware of, but
> technically, the soname, or filename based library versioning, doesn't
> matter if symbol versioning is used [1]. Symbol versioning can be used
> in different ways. For libmultipath, we don't attempt to provide
> multiple backward-compatible ABIs. We just want to avoid undefined
> behavior which would result from an executable calling a library
> routine with a different version of the ABI, and this is what our
> library versioning scheme achieves. The idea is similar to the kernel's
> symvers mechanism, which avoids loading binary-incompatible modules.
> 
> > So - I'm not sure if, for a Debian library package, it is okay to do
> > essentially drop symbols without a new soname.
> 
> I can't tell for Debian, but other distributions haven't complained so
> far. I don't think that multipath-tools is the only project that uses
> symbol versioning this way.
> 

[..]

> On rpm-based distributions,package management will be able to figure
> out this kind of (in)compatibility, albeit in a more coarse-grained way
> (e.g. the multipathd package requires
> libmpathpersist.so.0(LIBMPATHPERSIST_2.1.0)(64bit), which must match
> the provided features of the library package). I suppose something
> similar exists in the Debian realm, too.

Do you also rename the package that ships libpathmpersist.so.0 in
this case?

I.e. how do you make this example work:

old libmpathpersist.so.0 provides ABI 1
new libmpathpersist.so.0(?) provides ABI 2

multipathd was linked against the new libmpathpersist.so.0 (ABI 2)
qemu was linked against the old libmpathpersist.so.0 (ABI 1)

I don't see how these can be co-installable if libmpathpersist.so.0
is never renamed?

Maybe other distributions do not need coinstallability, but Debian
needs this, because a) on actual installs we support partial upgrades,
and b) we do not rebuild all reverse-dependencies of a library the
moment a new version of that lib is uploaded.


I also wonder you get from symbol versioning if the old symbols just
disappear. ISTM you could get the same effect - cannot by accident
load the wrong library version - just by bumping the soname, and
ignoring manual symbol versioning?


I asked around a bit and got "this seems very unusual" as feedback.


Thanks,
Chris