Re: please let mplayer into testing
A Mennucc wrote:
> Brief summary of bug: MPlayer contains an embedded copy of FFmpeg
> (indeed, they are developed by ~the same people); Aur=E9lien G=C9R=D4ME a=
> Moritz Muehlenhoff ask that the mplayer package be dynamically linked to
> the libraries in the Debian package ffmpeg; they consider this a RC bug.=
> Unfortunately, this cannot be currently done (mplayer does not compile
> with current ffmpeg package; and we are too late to update ffmpeg into
> Etch ; more details are in the above bug report).
> So we agreed to ignore that problem for the sake of the etch release
Where did I agree until now?
> Please hint MPlayer into Etch.
I've tried it myself and it is indeed not possible to link against
libavcodec dynamically currently. Given that mplayer was only accepted
into the archive 2.5 months after the current ffmpeg snapshot was made
and that mplayer is an important application I do now think we can
ignore this RC bug for Etch as a one-time exception. In any case further
mplayer maintenance needs to be synchronised with Debian's libav[codec|
format], even if it means to not being able to upload the most recent
upstream version every week.
Also, the static linking against libdv introduced in 1.0~rc1-4 should
> PS: actually, I personally do not agree to this bug being tagged
> "serious". We all know that dynamical linking is the recommended way
> to go (as stated in d-policy); but currently neither mplayer is apt to
> this (dynamic linking breaks many features); nor is ffmpeg, that does
> not have a stable documented API. And indeed most multimedia packages
> ship an internal copy of ffmpeg; some of these packages can be linked
> dynamically to the ffmpeg in Debian (e.g. libxine1) but some others
> cannot (e.g. gst-ffmpeg). AFAIK, "dynamic linking to ffmpeg Debian
> package" was never stated as a "release goal". So I really do not think
> that bug 395252 should be "serious".
It is serious, as it hampers Debian's ability to issue security updates
in a timely manner.