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. [EMAIL PROTECTED] http://www.debian.org/
