Eugen.Dedu at pu-pm.univ-fcomte.fr
Mon Mar 30 09:53:59 UTC 2009
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.
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...
More information about the Pkg-voip-maintainers