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
Attachment:
signature.asc
Description: This is a digitally signed message part.