Manoj Srivastava ha scritto: > Off hand, I can see several reasons not to carry around > private copies of code: including code bloat, duplication of code, > having to make security fixes in many places. Technically, there is > nothing stopping a proper packaging of the libavcode, with shlib and > soname bumps as needed, and all relevant packages depending on the > appropriate -dev package version. The issue here seems to be time > taken to bring all this into a state that is acceptable. In other > words, it seems like it would take time to reach a quality of > implementation that one would like to see in a Debian release. > I, in principle, agree. At the same time this principle should be weighted in its pro and cons. There are indeed some cons in going that way: dyn.lin. mplayer with ffmpeg is experimental, the mplayer code for that is not all ready, and then dyn.lin. will disable some features in mplayer. For that reason, dyn.lin. is currently deprecated by the MPlayer team; I have exchanged many emails about that, and they have sound reasons for that. So this is another con: I am not that happy to do something that upstream is asking not to do. Let me state this clearly: if (when) ffmpeg & mplayer will have better support for dyn.lin. , I will be the first one to immediatly implement it. But, as for Dec 2006, this is still a bit early. (Moreover, being in etch freeze is not the right moment to do huge library changes in code). This is for example very different from the situation of gst-ffmpeg : AFAIK, the patch by Josselin Mouette to dyn.lin. gst-ffmpeg does not disable some features in gst-ffmpeg (actually, it may add some new features, see http://lists.debian.org/debian-devel/2006/12/msg00161.html ) whereas the dyn.lin. of mplayer does disable some features. -- The other huge difference is that Josselin Mouette did not open a RC bug against gst-ffmpeg, and is not pushing for its exclusion from Etch. a.
Attachment:
signature.asc
Description: OpenPGP digital signature