[FFmpeg-devel] Upgrade Trouble

[Uoti Urpala]

On Mon, 2009-11-30 at 19:54 +0100, Reinhard Tartler wrote:
> Uoti Urpala <uoti.urpala at pp1.inet.fi> writes:
> 
> > On Sat, 2009-11-28 at 22:20 +0100, Reinhard Tartler wrote:
> >> Is my analysis correct? If yes, you can imagine that the shown testcase
> >> is exactly what happens in a distro setting. Media players have been
> >> built against FFmpeg 0.5, and upgrading FFmpeg packages will change the
> >> system in a very similar way as described here. How can the problem
> >> described in my mail avoided in an *elegant* way?
> >
> > You can add versioned symbols to future packages (or upstream FFmpeg if
> > possible).
> 
> I'm no expert in that feature of ld, and I have to admit that I never
> worked with that, but I'm not sure how symbol versioning could help
> here.  AFAIUI, it allows retaining binary compatibility while allowing
> API changes. This means in this case that libavutil would need to
> provide both the old and new FIFO API with different versions.

You've misunderstood something about it. You could use it that way
within a single package version, but that's not the common use case.

Symbol versioning means adding a 'version' attribute to (some of) the
symbols in the library. Symbol lookup can then use that to find a
matching version. So if a new library version uses a different version
value for all identically named symbols, a binary compiled against an
older version of that library can keep using the symbols from that older
library version even if there's also a newer library in the same
namespace.


> Wouldn't it be much more practical to declare that the version bump
> broke (indirectly) the binary compatibility of the intermediate
> libraries (libavformat, libavcodec, etc.), and thus, bump SONAME on *all*
> libraries that link against libavutil? I think that would be all
> libraries but libswscale.
> 
> This would allow FFmpeg 0.5 and current trunk to be installed in
> parallel and thus, make my life as packager a *lot* easier in this case.

This would fix things for programs that only have *direct* use of FFmpeg
libraries. However there could still be problems if a program uses other
libraries that internally depend on FFmpeg ones; those indirect
dependencies can still load any older library version into the process.