Thank you so much Chris for chiming in, that provided the background
info that I assumed would be out there.
To be fair there are plenty of soname 0 out there, without much guarantees and
the symbols files
handle most churn. But indeed allowing it would imply a transition every time
you bump a version, which would be small with one known dependency being qemu
then.
Maintaining DPDK I know exactly what you mean with "namespaced into a versioned
namespace, which changes on every release" but that was never as painful as it
sounds.
With that in mind it really seems to be about asking multipath-tools
again if they want to consider/treat this as more stable into the future
- or if they'd guide us in another way. They might say while unstable,
it is working fine because ... <reason>. Do you have a reference to
mail, chat or whatever was used back then to ask them in 2023?
P.S. The side experiment here is to trial and error creating a symbols file for
these lib(s) which will help to detect whenever we change it. If we ever go to
make them available again, that will be needed anyway. I'll add a
multipath-tools task for tracking that. If working there are four of them
overall:
$ dpkg -L multipath-tools | grep .so.0
/usr/lib/libmpathcmd.so.0
/usr/lib/libmpathpersist.so.0
/usr/lib/libmpathutil.so.0
/usr/lib/libmultipath.so.0
** Also affects: multipath-tools (Ubuntu)
Importance: Undecided
Status: New
** Changed in: multipath-tools (Ubuntu)
Status: New => Confirmed
** Changed in: multipath-tools (Ubuntu)
Importance: Undecided => Wishlist
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2117378
Title:
qemu-pr-helper doesn't have multipath support
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/2117378/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs