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

[Faidon Liambotis]

Mark Purcell wrote:
>> If you change the package name, you have to change the SONAME and the
>> filename too.
> 
> I'm not sure about that.  Isn't it the reverse that applies.
> 
> Ie if the soname changes then you need to change the package name to 
> something unique as they are not binary compatible and packages build 
> against the first library won't function with the second.
> 
> But it doesn't break if you rename the package, as often as you like, the only
> penalty is that all dependant packages need to be rebuilt every time the
> package name changes, which is nugatory if binary compatibility is maintained.
> But doesn't break anything. Refer to the suffix c102 libs packages Debian did a 
> couple of years back with a libc transition.
Right. But in this case it doesn't make sense to change the package
version without changing the SONAME.

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.

> Or should we just revert to the upstream soname and bump the package name to 
> libpri1.0?? Which we have never used and is thus safe? (oldstable is libpri1)
Well, I guess that's an option too.
I guess that we could use SONAME 1.0 instead of 1.2 and all the other
changes.

We only support upgrades from subsequent versions and a conflict on
libpri1 wouldn't be needed, so we should be safe.

It depends on upstream's intentions I guess.

Faidon