Sam Hocevar wrote: > On Mon, Jun 02, 2008, Joey Hess wrote: > > > libavcodec/libavformat (source: ffmpeg) > > - mplayer <unfixed> (embed; bug #395252) > > - xvidcap <unfixed> (embed) > > - kino <unfixed> (static) > > - vlc <unfixed> (static) > > - smilutils <unfixed> (static) > > - motion <unfixed> (static) > > - gst-ffmpeg <unfixed> (embed) > > - gstreamer0.10-ffmpeg <unfixed> (embed) > > - xmovie <unfixed> > > TODO: gimp-gap (potentially using ffmpeg code as well) > > > > > > BTW, in 2006, mplayer included a newer version of ffmpeg than the > > standalone package. That's not the case now. So is there any reason why > > mplayer should not statically link to the packaged version, as kino, > > vlc, etc do? > > Where does this data come from? I suspect there is something wrong > with the way it was compiled: VLC has been dynamically linking with > ffmpeg ever since the Debian packages shipped shared libraries (April > 2006), Kino uses shared ffmpeg libraries since 1.0.0-1 (uploaded in > May 2007), and I don't know precisely about the others, but motion and > smilutils also link dynamically with ffmpeg.
That is from the embedded-code-copies list in secure-testing svn. Of course it may be out of date (above hunk was changed in Jan 2008) -- but if we're serious about embedded code copies to the extent of calling it a hard release goal and throwing mplayer out of the release, having an up-to-date version of the file would seem to be the obvious place to start. -- see shy jo
signature.asc
Description: Digital signature
