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

[Mark Purcell]

On Fri, 3 Aug 2007, Faidon Liambotis wrote:
> I commited r3879 which does what I think is right and I propose.

This is the way to go..  At least by committing we are getting visibility,
of the options and see what the various impacts are..

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

Agreed!

> 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 :-(

Well almost, but we haven't uploaded yet, so we haven't gone
anywhere too bad yet... Apart from what is already broken of course ;-)

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

But it is unstable, I'm not that worried about breaking unstable, also
asterisk 1.4 hasn't migrated to testing yet, so we aren't yet trying to
maintain a status quo. Additionally testing is currently v.broken as we
have asterisk1.2 with incompatible libpri1.4 in lenny which isn't working.

However asterisk 1:1.2.13~dfsg-2 in stable also depends on libpri1.2 :-(
But shlibs can ensure a smooth migration for this.

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

As stated I'm not that concerned about a smooth upgrade for unstable, it
is called unstable and users should expect some instability...

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

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

This also makes us lintian clean ;-)

> Dunno. Comments

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

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/pkg-voip-maintainers/attachments/20070803/bbf6d67f/attachment.pgp