ptlib_2.3.0+svn20940-1_i386.changes ACCEPTED

[Eugen Dedu]

Hi Faidon,

Faidon Liambotis wrote:
> 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 :)

:o(

Given that ptlib and opal are in a stable branch and ABI changing has a 
low probability, because only bug fixes are checked in, I propose to 
push their last version (the one currently in alioth) in experimental 
via new queue.  This will finally allow ekiga 3 to enter experimental. 
We can stay with these versions for several months, in case the ABI 
changes and I cannot cope with the change.  What do you think?

I plan to get together two other ekiga maintainers (from other 
distributions) to discuss this issue with upstream.

(For info, there is an -fpic bug preventing ptlib in debian repository 
to be compiled on alpha, I am investigating this.)

Cheers,
-- 
Eugen