[dm-devel] multipath-tools: Debian patches

[Martin Wilck]

On Wed, 2023-06-07 at 17:12 +0200, Chris Hofstaedtler wrote:
> 
> > 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?

No, we don't. The ABI change is solely reflected in the library
package's symbol versions and abstract provides like the one I showed
above. The SONAME remains formally remains "libmpathpersist.so.0".

readelf -W -V -a reports:

Dynamic section at offset 0x8b78 contains 34 entries:
  Tag        Type                         Name/Value
0x000000000000000e (SONAME)             Library soname: [libmpathpersist.so.0]
...
Relocation section '.rela.plt' at offset 0x15e0 contains 60 entries:
    Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
0000000000009df0  0000004600000007 R_X86_64_JUMP_SLOT     0000000000003600 prout_do_scsi_ioctl@@__LIBMPATHPERSIST_INT_1.0.0 + 0
0000000000009df8  0000000100000007 R_X86_64_JUMP_SLOT     0000000000000000 __snprintf_chk at GLIBC_2.3.4 + 0
0000000000009e00  0000000200000007 R_X86_64_JUMP_SLOT     0000000000000000 free at GLIBC_2.2.5 + 0
0000000000009e08  0000000300000007 R_X86_64_JUMP_SLOT     0000000000000000 __errno_location at GLIBC_2.2.5 + 0
0000000000009e10  0000000400000007 R_X86_64_JUMP_SLOT     0000000000000000 strncmp at GLIBC_2.2.5 + 0
0000000000009e18  0000000600000007 R_X86_64_JUMP_SLOT     0000000000000000 libmp_put_multipath_config at LIBMULTIPATH_18.0.0 + 0
0000000000009e20  0000000700000007 R_X86_64_JUMP_SLOT     0000000000000000 puts at GLIBC_2.2.5 + 0
0000000000009e28  0000000800000007 R_X86_64_JUMP_SLOT     0000000000000000 select_reservation_key at LIBMULTIPATH_18.0.0 + 0
0000000000009e30  0000000900000007 R_X86_64_JUMP_SLOT     0000000000000000 dm_map_present at LIBMULTIPATH_18.0.0 + 0
0000000000009e38  0000000a00000007 R_X86_64_JUMP_SLOT     0000000000000000 put_multipath_config at LIBMPATHCOMMON_1.0.0 + 0
0000000000009e40  0000000b00000007 R_X86_64_JUMP_SLOT     0000000000000000 free_multipathvec at LIBMULTIPATH_18.0.0 + 0
0000000000009e48  0000000c00000007 R_X86_64_JUMP_SLOT     0000000000000000 strlcpy at LIBMULTIPATH_16.0.0 + 0
...


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

They aren't co-installable. But the dependencies make sure that
qemu, multipathd, and possibly other consumers will use the ABI version
that libmpathpersist actually exports. On openSUSE Tumbleweed, our
rebuild policy will ensure this. On the more long-lived products, we
usually can't update the ABI in a backward-incompatible way; our QA
tools would notice if we mistakenly tried. Severe security issues might
justify an exception, in which case we'd provide patches to update the
depending packages in a batch.

> Maybe other distributions do not need coinstallability, but Debian
> needs this, because a) on actual installs we support partial
> upgrades,

openSUSE supports that, too. In the case at hand, you would need to
update the "libmpath0", "multipath-tools", and "qemu-tools" packages
simultaneously. (If you'd try to update just one, the resolver would
tell you that the other two need to be updated as well).

> and b) we do not rebuild all reverse-dependencies of a library the
> moment a new version of that lib is uploaded.

Well, in this case the set of reverse-dependencies is rather small.

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

In theory, we could. I guess we could also use some heuristics to
transform the LIBMPATHPERSIST... string to a SONAME, making the
libraries co-installable. But so far we didn't need to, and tbh,
given the small number of users of our library, it doesn't seem to make
much sense. Feel free to send patches if you want.

One reason for the symbol versioning rather than SONAME is that it
makes the ABI changes more transparent to ourselves. Using abigail
to compare the latest code against the ABI of the stable version, 
we can figure out which parts of the ABI actually changed, and reflect
this in our libmpathpersist.version file.

Thus even if we were to support SONAME, I believe we'd continue using
the symbol versioning.

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

I'm sorry to hear that. But I see nothing in the docs that mandates
either providing multiple ABI versions, or modifying the SONAME just
because symbol versions are being used.

Regards,
Martin