Re: Bug#402793: tech-ctte: gst-ffmpeg links with its own private ffmpeg copy

[Loïc Minier <lool@dooz.org>]

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 <lool@dooz.org>