|
```
* CMP: =dev-cpp/pystring-1.1.3-r1 with dev-cpp/pystring-1.1.4/image
* FILES:-usr/lib64/libpystring.so.0.0
* FILES:+usr/lib64/libpystring.so (-rwxr-xr-x root:root)
* SONAME:-libpystring.so.0.0(64)
* SONAME:+libpystring.so(64)
```
This breaks binpackage usage. preserved-libs sort of saves you, maybe,
if you built locally. Reverse dependencies are linked to .so.0.0, but
the new package only contains .so -- technically, if the reverse were
true, linked binaries would still work if you squint, but in the current
state this simply does not work at all.
The background here is weird. Upstream has a Makefile, which calls the
system libtool (broken!) and produces a soname of .so.0 in the event
that it succeeds at producing a library. We patched in an unofficial
cmake build (???) that set the soname to .so.0.0 instead, which isn't
very libtool of them but whatever. Upstream didn't actually accept that,
they wrote their own which is "simpler" and set the soname to .so.
Now we have 3 different sonames in use, but one of them was only in use
in *Gentoo* for a couple of days, unstable, back in 2021.
As standard, we solve changing sonames by bumping subslot to force a
rebuild. Straight to stable it goes, with a revbump since people
already have it installed and now have broken binaries.
Bug: https://github.com/gentoo/gentoo/pull/21209
Bug: https://github.com/gentoo/gentoo/pull/39761
Bug: https://github.com/imageworks/pystring/pull/29
Fixes: 91773fd1eb57d4c080c0151f5899f1631ddf2aac
Fixes: 4b6bedcedfc6a2e7b8c59262dea3d3e42f248427
Signed-off-by: Eli Schwartz <eschwartz@gentoo.org>
|
