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>