Re: Shared library binary package, SONAME changes and file conflicts

Hey Andrey, thanks for the advice:

On Tue, May 5, 2015 at 9:49 PM, Andrey Rahmatullin <wrar@debian.org> wrote:

On Tue, May 05, 2015 at 09:09:10PM -0700, Tom Lee wrote:
> By and large that's an easy & mostly mechanical change, but both
> libhiredis0.10 and libhiredis0.13 want to install the libhiredis.so.0
> symlink (each pointing to one of libhiredis.so.0.{10,13}).
From the upstream perspective this looks like misunderstanding: this
symlink shouldn't exist when the SONAME looks like "libhiredis.so.0.10"
which is the case here.
>From the Debian perspective this violates Policy 8.2.

After reading a little more about shared lib naming & SONAME, I think I understand. So instead of the current libhiredis.so.0 symlink we want a libhiredis.so.0.13 symlink & the "real name" of the shared lib would be something like libhiredis.so.0.13.1? That would certainly make life easier.

> I *think* what I want to do based on
> https://www.debian.org/doc/debian-policy/ch-relationships.html#s-replaces is
> to add the following to debian/control for libhiredis0.13:
>
> Replaces: libhiredis0.10
> Breaks: libhiredis0.10
This defeats the purpose of shared library package design used in Debian.

Sorry, still learning the ropes.

> Is this the right way to handle the situation, or is there a better way to
> do this?
Ideally you should find out whether $(DYLIB_MAJOR_NAME) is really useful
to anyone and if it isn't convince upstream to drop it.

I'm happy to make the case upstream, but is it sane to work around this in the packaging while that gets figured out? (i.e. leave SONAME=0.13 & patch to change the "real name" to something like libhiredis.so.0.13.1 & symlink libhiredis.so.0.13 [+ libhiredis.so from the -dev package] to the new real name). I'm okay dealing with the maintenance overhead while we wait on upstream if it means I can push a new release.

It would of course be good to fix libhiredis0.10 eventually too, but even if somebody is using the .0 symlink it seems we could leave the current "bad" approach for the existing libhiredis0.10 alone without doing any more harm (unless I'm missing something -- entirely likely).

Tom Lee / http://tomlee.co / @tglee