ptlib transition

[Mark Purcell]

On Monday 30 March 2009 20:53:59 Eugen Dedu wrote:
> Adeodato Simó wrote:
> > Naming the development package without version information (libpt-dev)
> > is great, so thanks for that.
>
> Could someone explain why libpt-dev is so interesting compared to
> libpt2.6.1-dev?  The problem is that each new ptlib version will be
> incompatible with any other version, so each new ptlib version will lead
> to a rebuild of all its rdeps, and to a FTBFS too...

Eugen,

A couple of issues:

Not every version breaks API compatibility, a break in ABI compatibility can 
be fixed with a rebuild of rdeps, but only if a common -dev file is used. 
Source packages for each and all rdepends don't need to be reloaded. This is 
what we propose. This makes for good upstream development and long term 
support. Something we want to support.

A break in API compatibility presents more issues and does present FTBFS for 
rdeps.  This isn't good upstream practice as it requires fixes to the source 
code for all rdeps. 

popcon has an installed base of some 20,000 users with libpt-1.10.10, which is 
a old and unsupported lib but we have a few rdepends that haven't keep pace 
with the API changes. Thus we can't move on ;-( By making a common -dev 
package this forces the issue, bugs get filed against FTBFS and packages which 
don't keep up can be dropped.

How does ekiga work around the changes in API, are ekiga releases closely tied 
with ptlib releases?

Some interesting documents about the subject:
Preserving Backward Compatibility http://www.onlamp.com/lpt/a/5626
Parallel Installation http://www106.pair.com/rhp/parallel.html

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