On 01/19/2016 02:41 PM, Andreas Metzler wrote:
We can choose one of these hacks:
1 Find a way to ship unpatched libwraster 0.95.7 in Debian.
2a Patch the source to fix back the symbol versioning to
LIBWRASTER3
2b Patch the source to use a different soname. (If the ABI breaks in
an incompatible way, requiring rebuilds library maintance 101 says: bump
the soname.)
1 cannot be done /properly/. libwraster-0.95.6 and libwraster-0.95.7
have the same soname and are therefore not co-installable but would
need to conflict. So we cannot do the usual seamless partial upgrades,
it won't be possible to upgrade wmaker (built against
libwraster-0.95.7) while keeping wmweather+ 2.15-1.1 (built against
libwraster-0.95.6) functional.
Both 2a and 2b have the downside that Debian's libwraster/0.95.7 will
be binary incompatible with unpatched libwraster/0.95.7 (as possible
shipped by e.g. Fedora)
2a has the benefit of avoiding an actually useless library transition.
There is little to speak for 2b, except perhaps the fact that it shows
that our ABI differs from upstream.
So, having to choose I would strongly vote for 2a, adding attached
patch to debian/patches/ and updating the symbol file (again).
I have not got more time to spend on this today, but if you agree that
this is best course of action I can make an upload along these lines.
Ideally upstream would fix this instead of us.
Thank you for the clarification, Andreas! I completely neglected to
think about the fact that libwraster5 and my proposed libwraster5v2
would both be trying to install the same file.
Option 2a sounds good to me. Feel free to revert my last few commits if
you get to it before I do.
Just to clarify, would the best course of action for upstream to be to
go ahead and bump the soname for libwraster to 6 for the next release?
If so, I can prepare a patch.
Doug
