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@GLIBC_2.3.4 + 0
0000000000009e00 0000000200000007 R_X86_64_JUMP_SLOT 0000000000000000 free@GLIBC_2.2.5 + 0
0000000000009e08 0000000300000007 R_X86_64_JUMP_SLOT 0000000000000000 __errno_location@GLIBC_2.2.5 + 0
0000000000009e10 0000000400000007 R_X86_64_JUMP_SLOT 0000000000000000 strncmp@GLIBC_2.2.5 + 0
0000000000009e18 0000000600000007 R_X86_64_JUMP_SLOT 0000000000000000 libmp_put_multipath_config@LIBMULTIPATH_18.0.0 + 0
0000000000009e20 0000000700000007 R_X86_64_JUMP_SLOT 0000000000000000 puts@GLIBC_2.2.5 + 0
0000000000009e28 0000000800000007 R_X86_64_JUMP_SLOT 0000000000000000 select_reservation_key@LIBMULTIPATH_18.0.0 + 0
0000000000009e30 0000000900000007 R_X86_64_JUMP_SLOT 0000000000000000 dm_map_present@LIBMULTIPATH_18.0.0 + 0
0000000000009e38 0000000a00000007 R_X86_64_JUMP_SLOT 0000000000000000 put_multipath_config@LIBMPATHCOMMON_1.0.0 + 0
0000000000009e40 0000000b00000007 R_X86_64_JUMP_SLOT 0000000000000000 free_multipathvec@LIBMULTIPATH_18.0.0 + 0
0000000000009e48 0000000c00000007 R_X86_64_JUMP_SLOT 0000000000000000 strlcpy@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
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel
