ptlib_2.3.0+svn20940-1_i386.changes ACCEPTED

[Faidon Liambotis]

Eugen Dedu wrote:
> Glad to see that ptlib has finally been accepted into debian.  Now, two 
> stable releases have been done since then, the current one is 2.4.2 and, 
> for opal, 3.4.2.  The files in alioth are updated for that.  If you 
> think it's good to submit them, please do it.
> 
> The problem is the following: the soname of ptlib and opal is identical 
> to the library version, and they change the library version / soname 
> (hence the name of the debian package) very often.  For example, 2.4.1 
> was marked as stable one month ago, and one week ago 2.4.2 become the 
> new stable in the same 2.4 branch.  They do not want to have a 2.4 
> soname, because sometimes they break the compatibility.  This has a very 
> negative effect: each time a (minor) stable version is released, the 
> name of the debian package changes, so it goes again through new queue. 
>   Is there a way not to wait each time the new queue?  What do you 
> think?  In fact, I expect that in another month there will be another 
> stable version for ptlib and opal.  How can we track them in debian???
Delay of NEW is the least of our problems.

Everytime you bump the SONAME and change the package name, each one of
the reverse dependencies needs a binNMU in each of the 13 architectures.
Plus, all of the binaries that the user self-compiled would need to be
rebuilt.

Minor versions shouldn't bump the SONAME.-

You should convince upstream to be more careful about breaking
compatibility. If you fail to do that, check for such changes yourself
and change the SONAME only when needed or revert incompatible-changes.

We can't afford *breaking* binary compatibility at each minor release.
I'm sorry, but that's the price you're going to have to pay for having
stupid upstreams :)

Regards,
Faidon