-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Reinhard Tartler ha scritto: > xine is able to build against an out of tree ffmpeg. This is what the > current xine in etch is doing.
(I was aware of this; I hope I made it clear in previous emails ) > So far, I'm not aware of any regressions > yet. I am aware that an updated ffmpeg could introduce regression. > Therefore I rely that Sam will bump the SONAME of the libraries when he > updates an incompatible version of ffmpeg in debian. (disclaimer: I am not expert of SONAME details, so please bear any error) there may be a misunderstanding here AFAIU the whole point that is asked by Aurélien GÉRÔME and Moritz Muehlenhoff is that there should be less copies of ffmpeg around I try to clarify things: currently $ objdump -p /usr/lib/libavcodec.so.0d.51.11.0 | grep SONAME SONAME libavcodec.so.0d Suppose Sam packs a new FFMpeg package from current SVN, and, since it is is incompatible with xine and other sw already using libavcodec0d , it puts it in binary libavcodec1d and gives it a SONAME of libavcodec.so.1d; then I may link MPlayer with that lib, with no fear of breakage. But this would not solve the original question of having one less copy of ffmpeg around, right? unless also all other sw would be modified to work with the new libavcodec.so.1d , and libavcodec0d is removed from etch. so again: > Therefore I rely that Sam will bump the SONAME of the libraries when > he updates an incompatible version of ffmpeg in debian. would you then update/patch xine to link with that ? how feasible is that ? (e.g. is there an upstream version of xine using a newer ffmpeg? ) a. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFThnd9B/tjjP8QKQRAlecAJ9mD5qC4uuwEtfssELCPFC3QQES4gCcD+hX MGOdODaMxRutWdjzYaWg3Do= =K2WJ -----END PGP SIGNATURE----- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
