[Pkg-voip-commits] r3877 - libpri/trunk/debian

[Faidon Liambotis]

Faidon Liambotis wrote:
> I commited r3879 which does what I think is right and I propose.
> 
> Also, note that libpri 1.4 is backwards-compatible with libpri 1.2, so
> Asterisk 1.2 can use it. But it's not the other way around, Asterisk 1.4
> can't use libpri 1.2 and that's because a new function was added (among
> other things).
> 
> Thus, we "need" to use dh_makeshlibs -V. We were already using that but
> without arguments, which resulted in a shlibs of "libpri1.2 (>= 1.4.1)".
> This is too strict IMHO, since all 1.4 releases should be compatible.
> 
> Hence my changes on commit r3880.
> It's a bit of a hack so I'd appreciate comments.
Members of the release team (aba, dato) verified that a shlibs bump is
the way to go, so everything should be fine.

But they're not, I just broke unstable's Asterisk :-(

Currently, Asterisk depends on libpri1.2 (>= 1.4.0) and uses
libpri.so.1.0. trunk's libpri is libpri1.2 1.4.1 but doesn't provide
libpri.so.1.0. Bummer.

Possible solutions:
a) Add a Conflicts on the older Asterisk in libpri
b) Add a softlink libpri.so.1.0 -> libpri.so.1.2 in libpri. I.e. we
didn't gain anything
c) Leave current Asterisk broken and upload a new one or ask d-release
for a binNMU. Revert the r3880 since that would create an Asterisk that
would be broken using the old libpri (sigh...)
d) Change SONAME=1.2 to SONAME=1.0 on my patched Makefile and change the
package name to libpri1.0 = revert the SONAME change as discussed
previously with Mark.

All of these suck in a different way.
(a) or (b) could be done temporarily and stop providing a smooth upgrade
path from e.g. a 1 month old unstable.

This or (d), even though an upgrade from libpri1.2 to libpri1.0 would
sound a bit funny.

Dunno. Comments?