ptlib transition

[Eugen Dedu]

Adeodato Simó wrote:
> * Mark Purcell [Sat, 21 Mar 2009 10:06:19 +1100]:
> 
>> Debian Release,
> 
> Hello again,
> 
>> I propose ptlib 2.6.1 will supply the binary package libpt-dev with Provides: 
>> libpt-1.11.2-dev, libpt-2.4.2-dev for backwards compatibility (to an extent). 
>> This is different to how ptlib has been provisioned previously in Debian and 
>> will cause some transition pain for the voip team, but the end state will be 
>> worthwhile as we will be back on upstream trunk with the current development 
>> roadmap. The use of a clean libpt-dev package (without soname) is also in line 
>> with current direction from the release team as it provides for much smoother 
>> transition and binNMU ability for rdepends.
> 
> I don’t think the Provides are needed at all. Or rather, I don’t think
> they’re going to buy as anything at all: since libpt2.4.2-dev is only in
> experimental, no package in unstable Build-Depends on it; and packages
> in experimental that do (ekiga and opal) will need sourceful uploads to
> unstable, and the build-dependency can be changed into “libpt-dev (>=
> 2.6)” when uploading to unstable. As for libpt-1.11.2-dev, all two
> packages Build-Depending on it in unstable (openmcu and openh323-titan)
> have a versioned build-dependency, so the provides won’t solve anything.
> I would suggest to skip the provides, then, but they of course won’t
> hurt anything.
> 
> Naming the development package without version information (libpt-dev)
> is great, so thanks for that.

Hi,

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