On Tue, Dec 12, 2006, Josselin Mouette wrote: > I kindly ask the Technical Committee to rule on the gstreamer0.10-ffmpeg > case.
While I would personally value the tech-ctte as a mean to resolve problematic technical issues and in some cases save us of flames, I don't think it was needed for this issue. It's not very clear whether you think I'm objecting to the changes in all cases, or only before etch. I am against such a change before etch in all cases given where we stand in the release cycle. > The gstreamer0.10-ffmpeg package includes its own private ffmpeg copy > and is built against it. Upstream's rationale is that ffmpeg's API and > ABI aren't stable and that they need a frozen version. Linking to > another ffmpeg version often requires changes to the code and means the > software cannot be as widely tested as the upstream version. That's correct. I would add that upstream is maintaining an organized fork which has other features (such as being autotools based), and which offer finer grained control for them to pull anything they need from the ffmpeg internals if need be; this is obvisouly not necessary currently as your patch demonstrates. Another important point is that the list of GStreamer "caps" (codecs) must be in sync with the supported codecs of the underlying ffmpeg. > However, the multiple copies of ffmpeg in the archive have been > responsible for a security nightmare during the sarge stable cycle. (While I was inclined to think that ffmpeg was a security nightmare, I found only one DSA on ffmpeg in the last 4 years.) But it's enough to consider code copies as evil and the fact that gst-ffmpeg is typically used to read remote media files. It's not like I ever questionned that. In fact *I* filed GNOME #363363: It would be nice if gst-ffmpeg would be built against an out-of-tree ffmpeg snapshot. It's currently painful (for you) to update the ffmpeg snapshot in gst-ffmpeg and autotoolize it, and it's painful for distributions to fix both ffmpeg and gst-ffmpeg if a security problem appears. > The > security team has asked to replace all such private copies by dynamic > linking to the debian ffmpeg packages. For example, this is holding > mplayer out of etch. Yes, and at this time I clarified the nature of gst-ffmpeg with the security team, and they considered the fork to be acceptable for etch (see #395252). Back then, I didn't think gst-ffmpeg would build against the libavcodec / avformat APIs as I thought gst-ffmpeg was also linking directly with some object files. Your latest patch shows that it is possible with the current gst-ffmpeg CVS. > However the maintainer does not want any such change before the release That's correct. I also will put some form of upstream acceptance as a pre-requisite for usage in Debian, even after etch, as I don't intend to fork gst-ffmpeg if I lose upstream support. If upstream accepts the change (for Debian), I accept the additional maintenance burden of updating GStreamer caps in gst-ffmpeg as new ffmpeg source packages will be uploaded to the archive and will likely break gst-ffmpeg. -- Loïc Minier <[EMAIL PROTECTED]>