libpri1, libpri1.2, SONAMES etc.

[Faidon Liambotis]

Mark Purcell wrote:
> On Sun, 22 Jul 2007, Faidon Liambotis wrote:
>> PLEASE DO NOT UPLOAD A NEW libpri TO Debian BEFORE DISCUSSING THIS.
>> It will only make the mess worse.

> Have we arrived at a concensus?
No we haven't yet, I think.

I didn't have the time to test whether libpri 1.4 works with Asterisk
1.2 yet, unfortunately.

> 1.4.x soname:  libpri.so.1.0    packagenames: libpri1.0 libpri-dev
> 1.2.x sonames: libpri.so.1.0 libpri.so.1.0   packagenames: libpri1.2 libpri1.2-dev
> 
> libpri1.0 to conflict with libpri1.2
That's certainly wrong.

There are two scenarios:
a) They're ABI-incompatible: they should have a different SONAME (e.g.
libpri.so.1.4/libpri.so.1.2) therefore a different package name
(libpri1.4/libpri1.2) and they shouldn't *AT ANY CASE* conflict each other.

b) They are ABI-compatible: we should drop libpri 1.2, pick one SONAME
for libpri 1.4 (probably libpri.so.1.2, I think libpri 1.0 had a
different ABI) and the according package name (libpri1.2).
Also, use "dh_makeshlibs -V libpri1.2 (>= 1.4)" because the
compatibility is going to be one-way (Asterisk 1.4 isn't able to use
libpri 1.2, obviously)

Based on the header diff, I believe that they are compatible, so (b)
will apply.
However, they may have a changed the internal behavior in a way that
Asterisk 1.2 doesn't expect, in which case we should go for (a).

That's where we left off, I was supposed to runtime test it inside the
week. Real life issues prohibited me from doing this since this point
and I'm not sure when I'll test it. Definitely in days though.
If Tzafrir wants to step-up, that's OK too :-)

If libpri 1.4.1 is something urgent (e.g. security bug or blocking a
security bug) then go for it without any changes (compared to the
current version in unstable) wrt SONAMEs, package names and/or Conflicts.

I'm sorry for the delay :/

Regards,
Faidon