-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 hi
I would like to add my 2¢ (although Dario's email pretty much says it all) Here are 3 possible scenarios: [N] The safest way to linking MPlayer with dynamical FFmpeg would be : each time there is a MPlayer release, Diego provides us with the correct SVN release number for FFmpeg, and both the proper mplayer and ffmpeg package are uploaded into Debian at the same time. [O] we forcibly link MPlayer to the older FFmpeg. To do this, we would need to extensively patch the version of MPlayer in Debian. In practice, we would break MPlayer, as people expect it to be: many features that are into 1.0rc1 are due to the new ffmpeg, and they would be lost. [A] We leave things as they are now. MPlayer links tonew FFmpeg inside it; ffmpeg outside is left unchanged (...we are near the freeze...). Some comments: Sam Hocevar (mantainer of ffmpeg) in March had expressed concerns similar to that in the bug; I have then contacted him to hear also his opinion about [N] (I did yet not receive a response). The problem of [N], as Diego was pointing, is that FFmpeg does not have a solid API yet. We cannot exclude that an update of FFmpeg may break Xine, or other packages. I checked that xine ships a old and patched FFmpeg library inside, but the Debian package is currently linked to the external FFmpeg ; whereas the version of FFmpeg that is inside MPlayer is even newer. I have contacted Siggi Langauf (mantainer of Xine) to hear his opinion as well (I did yet not receive a response). The overhead [O] may simply be not worth the (supposed) future benefit for security. Since the development of FFmpeg is done jointly with the development of MPlayer , then a security bug in FFmpeg will be fixed in upstream MPlayer before than in any other package using FFmpeg. In case [O] , applying the fix would require sorting also thru our patches (and we cannot even ask help upstream !). In case [N] , it may be the case that the fix is more easier to apply. In case [A] , we have double work to do (but I will take care of the fix for MPlayer, I promise :-) So I think that [O] is not worth the effort: we ruin MPlayer (for sure) for hope of a (not sure) benefit in security. (I really want to abide to (4): We will be guided by the needs of our users and the free software community. ) [N] is too far fetched So here is my proposal: let us stick with [A], and downgrade this bug for the time of the Etch release; in a year or so, it may be that FFmpeg will be stable enough that we really can try [N] for the next release. a. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFR82c9B/tjjP8QKQRAkLqAJ9wY4dUjlKAWV19O9Z9kdFtoLAnswCfXK0i DhgvIpEc+oxgkV8rbYfoCRA= =xpc5 -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
