Just wanted to upload a straw man example of what I'm talking about:

http://mentors.debian.net/debian/pool/main/h/hiredis/hiredis_0.13.1-1.dsc

And the result of installing this package over the top of an existing
libhiredis0.10 install:

https://gist.github.com/thomaslee/c97582fd4a7ba80f9abf

Cheers,
Tom

On Tue, May 5, 2015 at 10:43 PM, Tom Lee <deb...@tomlee.co> wrote:

> Hey Andrey, thanks for the advice:
>
> On Tue, May 5, 2015 at 9:49 PM, Andrey Rahmatullin <w...@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 <http://twitter.com/tglee>
>
>


-- 
*Tom Lee */ http://tomlee.co / @tglee <http://twitter.com/tglee>

Reply via email to