Package: release.debian.org
Severity: normal
User: release.debian....@packages.debian.org
Usertags: binnmu
libopensm5 ships three libraries with independent soversions.
One of them had an unnoticed soversion bump at some point, rendering
packages build against the old version installable but unusable.
#769742
libopensm5
Reverse Depends:
opensm same source as libopensm5
libopensm-dev same source as libopensm5
libibnetdisc5 OK
infiniband-diags OK
libibdm1 OK
ibutils BROKEN
# ldd /usr/bin/ibis # a binary from ibutils
linux-vdso.so.1 (0x00007fffdadfc000)
libopensm.so.5 => /usr/lib/x86_64-linux-gnu/libopensm.so.5
(0x00007fa47d615000)
libosmvendor.so.3 => not found
libosmcomp.so.3 => /usr/lib/x86_64-linux-gnu/libosmcomp.so.3
(0x00007fa47d406000)
....
libopensm5 ships libosmvendor.so.4 nowadays
Since it is too late for doing a proper transition for jessie,
I would suggest to do a binNMU of ibutils (in jessie? or sid?)
and tag #769742 jessie-ignore
nmu ibutils_1.5.7-3 . ALL . jessie-proposed-updates . -m "Rebuild against
opensm 3.3.18"
Is that the correct syntax? Do jessie binNMUs work that way?
Since the version in jessie and sid is currently the same,
would a jessie-binNMU be copied to sid afterwards?
(This binNMU can probably be done safely in sid, too, if it
is possible to migrate the binNMU. But what about cases where
a binNMU in sid would pickup dependencies that cannot go to
jessie?)
Andreas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
