A Mennucc <[EMAIL PROTECTED]> writes: >> 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
Which I also think is a good idea, since this way, we share bugs and
security issues, which can be fixed in a centralized way.
> I try to clarify things: currently
> $ objdump -p /usr/lib/libavcodec.so.0d.51.11.0 | grep SONAME
> SONAME libavcodec.so.0d
Let's go through a potential ffmpeg update in detail:
Sam prepares a new ffmpeg package. There are basically 3 possibilities:
a) the update doesn't change anything at the (exposed) interface to
applications
b) the update introduces additional symbols, and doesn't change
semantics
c) the update removes symbols or changes semantics to existing
functions.
a) isn't critical at all and can be uploaded without any
coordination. Most updates to packaging or configure options fall to
this category.
b) isn't too critical as well. You just need to make sure that an
mplayer binary which is built against this update isn't used with an
older ffmpeg binary package. This is done using the debian shlibs system
in an (semi) automatic way. In this case, Sam needs to update the
dh_makeshlibs call in his debian/rules, and the dh_shlibdeps of
debian/rules of the mplayer package will generate correct versioned
dependencies.
c) is critical, because binary packages which got built against the
current package NEED to be rebuilt against the updated package. In this
case (and only here) upstream (well, Sam in this case) needs to "bump"
the SONAME, and Sam needs to change the name of the binary package. When
he uploads this to unstable, all depending package will become instantly
uninstallable, until they get rebuilt.
Sam told me on irc that he check every package using ffmpeg that it
still builds with the updated ffmpeg package. If he could provide such
updated packages in experimental, I'd be happy to upload newer package
to experimental as well for testing to build and look for (potential)
regressions. Then we could coordinate an upload of all ffmpeg
related/using packages.
> 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.
Yes, this is case c) from above.
> 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.
since all package using libavcodec0d become uninstallable when it gets
superseeded by libavcodec1d, all package should better be rebuilt
against the newer ffmpeg sooner than later.
> 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 ?
So far, I didn't notice any problems with ffmpeg updates yet. xine is
focusing on an internal snapshot and only supports its interface, but as
said, I didn't have problems yet. I know that problems due to ABI/API
changes aren't too unlikely, and in this case, I'd have to look for an
patch from xine cvs for a newer ffmpeg.
> (e.g. is there an upstream version of xine using a newer ffmpeg? )
xine 1.1.2, which is currently in etch, uses and older ffmpeg snapshot
internally. I didn't spot any problems using the newer ffmpeg debian
(other that the newly introduced ffmpeg features like WMV9 support isn't
available in 1.1.2). The current cvs, which will become xine 1.1.3 is
using an newer ffmpeg snapshot. I'm uploading that branch from time to
time to debian/experimental for regression tests.
--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4
pgpNF7NqP1VuW.pgp
Description: PGP signature
