On Sat, Dec 16, 2006, A Mennucc wrote: > we delete ffmpeg from Debian stable, > since it is not really a library yet
We can also keep ffmpeg (the binary), without its lib. :) > so we also delete ffmpeg from inside: > libxine1 , used in xine-lib builds against Debian's ffmpeg AFAICT, *not* against its internal copy (it build-deps against libavformat-dev, libpostproc-dev, libavcodec-dev). If we did not have a ffmpeg shared library, I suppose we would still be able to build xine-lib without ffmpeg support. > totem-xine > xine-ui > gxine > [other 20 programs] No need to drop xine-lib, not these; only disable ffmpeg. > gstreamer-ffmpeg , used in > totem-gstreamer > openoffice.org > libgnash0 [flash implementation] > gnomebaker > geekast-binary > bmpx (And way more packages.) But please note that gst-ffmpeg is a real fork of ffmpeg which applies stability and functionality fixes around its snapshot in order to fix ffmpeg regressions. This is all wrapped in the GStreamer (stable) API transparently, and the program you mention are still usable without gst-ffmpeg (gst-plugins-base, -ugly, -bad also provide codecs). Now instead of imagining we remove ffmpeg, perhaps you can imagine that ffmpeg moves to offering a stable API, perhaps in a stable branch which is feature frozen but where security fixes can go, we could: - build mplayer, xine-lib, gst-ffmpeg against the ffmpeg shared libs - fix security holes in a single place - upload new ffmpeg versions without breaking mplayer, xine-lib, gst-ffmpeg or requiring a rebuild Doesn't it sound nicer? :) Why is ffmpeg so rapidly API breaking? xine-lib and GStreamer have managed to expose very stable APIs for years, and they solve the same type of problems. -- Loïc Minier <[EMAIL PROTECTED]> "Forget your stupid theme park! I'm gonna make my own! With hookers! And blackjack! In fact, forget the theme park!" -- Bender
