Bug#402772: bug 402772: downgrade mplayer bug 395252 (for including mplayer in etch)
On Tue, Dec 12, 2006 at 09:17:10PM +0100, A Mennucc wrote:
> This question is urgent, in the sense that I would like your help about
> bug 395252, that as so far stopped mplayer from entering in Etch.
> Brief summary of bug: MPlayer contains an embedded copy of FFmpeg
> (indeed, they are developed by ~the same people); Aurélien GÉRÔME and
> Moritz Muehlenhoff ask that the mplayer package be dynamically linked to
> the libraries in the Debian package ffmpeg (instead of statically
> linking with the copy shipped in the star of MPlayer); they consider
> this bug a RC bug.
> I do not think that this bug is "serious" & RC; and, moreover,
> I do not think that MPlayer deserves to be kept out of Etch on
> the basis of bug 395252.
There are multiple levels of ugliness when it comes to handling libraries:
- shipping an embedded copy of the library in the source tree. This adds
to the number of source packages that need to be patched every time there
is a security bug in the lib.
- statically linking to the library provided by the separate library source
package. This is better for security support than the previous option,
because the package needs only a rebuild for the security update, not
separate fiddling with the source.
- dynamically linking to the shared library. This is optimal for security
support, though of course there may be other problems with this (lack of
stable ABI; the mentioned performance issues on i386 due to register
constraints).
Now it's probably not reasonable to require shared linking for mplayer as a
release-critical requirement, especially when there are known problems with
that approach and this would single out mplayer to an extent that other
packages are not. But a) I haven't seen anything to really indicate it's
the security team's intention to require this, and b) right now mplayer is
at the far end of the spectrum, bundling its own copy of the libs in the
source. There is a middle ground here, which is mplayer statically linking
against the common ffmpeg package; I think that would be a reasonable
compromise, and I'd like to know if there are reasons this too isn't
achievable for etch. There may be known reasons, of course -- it's just not
clear to me which of the reasons for not dynamically linking also apply to
statically linking, and whether the issues with static linking might be
surmountable.
Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
vorlon@debian.org http://www.debian.org/
Reply to: