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

[Faidon Liambotis]

Mark Purcell wrote:
> However asterisk 1:1.2.13~dfsg-2 in stable also depends on libpri1.2 :-(
OUCH.
Thanks for noticing, that would be so *bad*.

> But shlibs can ensure a smooth migration for this.
No, they can't, what's done is done.
asterisk-classic/asterisk-bristuff 1:1.2.13~dfsg-2 depend on libpri1.2
(>= 1.2.4) which is satisfied by newest libpri.

>> 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.

>> (a) or (b) could be done temporarily and stop providing a smooth upgrade
>> path from e.g. a 1 month old unstable.
Based on the new data wrt etch, we'd have to maintain (a) and (b) for
the release of lenny. Sucks.

> (d) is OK, as we are upgrading from libpri1.2 (1.4.0-2) to 
> libpri1.0 (1.4.1-1) and in reality most people aren't even going to 
> notice that the 'tag' is going backwards.  They will just install
> asterisk and automatically pull in which ever dependencies are necessary.
I'm inclined towards that myself. It's wrong since this is not
compatible with libpri 1.0 (yes, I checked :) but OTOH a) it's oldstable
and b) nobody cares.

> This also makes us lintian clean ;-)
Well, lintian issued the warning for a good reason :)

> I'm pretty happy, but I guess if pressed I would go for (d).
I'm not :(

On a totally unrelated issue, we haven't thought what would happen if
kapejod decides to break his ABI on a newer bristuff.
The proper solution would be to have a separate package providing the
bristuffed libpri (libpri-bristuffed1.2 or may be libbri1.2).
I'm not sure if we want to get in the trouble of doing this since
kapejod hasn't showed signs of ABI-brokeness in the past. Not until that
happens anyway.

Faidon