It's a partner bug. I could open it up but it's simple: On SLE 15-SP3 or Leap 15.3, it's possible to update to multipath-tools-0.8.5+80+suse.73c50f5 without updating libmpath0, causing bad breakage.

I used to rely on the automatic dependency on libmultipath.so.0, which turned out to be insufficient in this case because I'd overlooked an API incompatibility.

On Factory we've got 0.8.6 which uses library versioning. So problems like this are unlikely to happen even without this explicit "Requires:". OTOH, libmpath0 and multipath-tools are really tied so closely together that installing different versions of the two makes no sense.

If you have a better suggestion, please inform me.

Jan Engelhardt (jengelh) - over 2 years ago

reviewer

Well that would be my suggestion, library versioning (symvers), on all levels.

1. If a library is missing them, a set of fixed symvers can be added (libpff.spec for an example)
2. if a library has problematic symvers, they can be thrown out and replaced by method 1.

So then the Requires isn't needed. (rpmlint also prefers symvers over spec-level Requires)

---

Martin Wilck (mwilck) - over 2 years ago

author source maintainer

As I said, it's not strictly necessary on Factory (but on SLE/Leap). OTOH the two packages are really strictly connected (libmultipath is changing all the time and has no real public "API"). By using the Requires:, we are on the safe side and are consistent with SLE/Leap, without a negative impact on Factory.

Anyway, if you feel strongly about it, just reject this PR. In that case I'll just add a bugref to the changelog entry that introduced the library versioning.