ptlib transition (was: libdc1394 should be removed (transition blocker 516826)

[Adeodato Simó]

* Mark Purcell [Sat, 21 Mar 2009 10:06:19 +1100]:

> Debian Release,

Hello again,

> I am proposing to upload ptlib 2.6.1 to unstable which will start a 
> transition.  All elements of the transition are contained within the pkg-voip 
> team with the exception of ekiga, which needs ptlib > 2.x to build, so I 
> suspect they are supportive of this transition to experimental.

This is not going to be, I think, as painful as it sounds, because the
new library will be provided by a new source package. Please proceed at
your earliest convenience.

> 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.

> This upload will also remove the dependency links with lib1394 and we have 
> coordinated with the 1394 team.

This is great as well. Once the ptlib transition is complete, pwlib and
pwlib-titan can be dropped from testing, and libdc1394 can go with it,
almost!

> A similar but related transition is also required for the upstream
> change with libopenh323 -> h323plus.

There seem to be two versions of libopenh323 (source packages openh323
and openh323-titan). Are both of them going away in favour of h323plus?

> We are currently maintaining too many versions of ptlib in Debian:

> ptlib (2.4.2-3) experimental.

> Other historic versions include:

> pwlib-titan (1.11.2-3) - was really a upstream ptlib but we didn't rename
> pwlib (1.10.10-3) - was really a upstream ptlib but we didn't rename

> Historic libs should be depreciated but we still have a few rdepends:

Will all those move to using ptlib 2.6? It would be indeed great to drop
pwlib and pwlib-titan once ptlib 2.6 is in testing.

So, to summarize: please go forward with ptlib 2.6 and h323plus, come by
for any needed actions, and thanks for your patience.

As you probably guessed, we didn’t give the “Go!” earlier because
libcommoncpp2 and libosip2 were tied to the ffmpeg/libraw1394
transitions.

Cheers,

-- 
- Are you sure we're good?
- Always.
        -- Rory and Lorelai