--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: transition: celt
- From: Ron <ron@debian.org>
- Date: Sat, 26 May 2012 18:38:11 +0930
- Message-id: <20120526090811.7081.20212.reportbug@audi.shelbyville.oz>
Package: release.debian.org
Severity: normal
User: release.debian.org@packages.debian.org
Usertags: transition
Hi,
We'd like to remove the celt package from the distro for the Wheezy release.
CELT was an experimental codec from Xiph, and that work has now been merged
into the Opus codec which is about to be ratified as an IETF standard.
As a result of that, upstream is no longer maintaining celt at all, and being
an experimental codec, no two releases of it were ever bitstream compatible
with each other (and only one release was ever made that even maintained API
compatibility with prior versions). All packages using it at the time knew
and accepted that this would be the situation with it while it evolved ...
The version that Debian currently is shipping we tried to get consensus on
people agreeing to consider it an interoperability snapshot before squeeze,
but in the end that never actually happened in practice and other distros
shipped other incompatible versions of it anyway.
So we (meaning myself, upstream, and anyone else who has discussed this with
us in detail) see little value in continuing to ship this, and plenty of
opportunity for Harm. Apps using it in Debian will only be interoperable
with the Debian releases of themselves, there will be no security support,
and it will just further fragment the codec space, at a time when there
is a real standard alternative people should be looking at for the future.
I'd have moved on this sooner, but it's only been in the last few days that
we actually had enough certainty about the IETF process concluding to really
know what the foreseeable future of all this was going to be. I've already
been actively talking to upstreams of the affected packages to be sure we
might actually pull this off in the time we have remaining, and I'm sure
enough that this will be possible now to really propose a formal course of
action for Wheezy. We've been planning for this in general terms for years
now, but nothing could actually move until the IETF did. And now they have.
Death, taxes, and bad timing.
Anyhow, this actually should be fairly simple, being an experimental codec
almost everything already has support for only optionally enabling it. So
we just need sourceful uploads of packages to turn it off - then celt can
safely be removed.
Some of the deps have already been updated to remove it, the remaining ones
as of yesterday were:
# Broken Depends:
gst-plugins-bad0.10: gstreamer0.10-plugins-bad
jack-audio-connection-kit: jackd1
jackd2: jackd2
libjack-jackd2-0
mangler: libventrilo3-0
opal: libopal3.10.4 [amd64 armel armhf i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390 s390x sparc]
roaraudio: libroar2
roaraudio
Opal I've been told will remove it with its next upload.
Mangler appears to be under control, details here:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=674244
gst, I've spoken to upstream and this is a no-brainer, but I still
need to get a ping back from slomo about updating the package.
jack should be just disable the option too, but I'm still chasing its
Debian maintainer for confirmation of doing it. Worst case I should
be able to do a trivial NMU myself.
Roar, I've been assured by its upstream is likewise easy to just disable
support for it - but the-me is giving me some pointless pushback ...
I'll NMU that too when the time comes if really needed if this is the
final blocker.
There shouldn't be any other flow on from this so far as I know.
Some of these packages may enable Opus support instead, but doing so
is not a prerequisite for us being able to remove celt for Wheezy.
Thanks!
Ron
--- End Message ---