[FFmpeg-devel] FOMS 2009 FFmpeg outbrief

[Aurelien Jacobs]

Reimar D?ffinger wrote:

> On Mon, Jan 26, 2009 at 09:52:19PM +0100, Reinhard Tartler wrote:
> > Now something interesting happens: with the new ffmpeg snapshot
> > libavutil is updated as well. It features a function rename
> > (ff_gcd->av_gcd), which is according to the ffmpeg development policy
> > OK, since it is a pure private function. However this rename breaks the
> > libavcodec51 package horribly. [3]
> 
> Hm, can't libavcodec be linked to always use/prefer the libavutil version it
> was linked to originally? Then bumping the minor version on such renames
> would reduce the issue...
> 
> > In the end this means that libavutil49 must not be renamed until *all*
> > applications linking against any library of ffmpeg has been recompiled.
> 
> I don't understand what you mean by "libavutil49 must not be renamed"...
> Overall I wonder if it wasn't a really bad idea to give each libav*
> library a different version number, or at least not bumping major
> versions together, because it seems to me that is what
> causes the issue in the end...

This is indeed the root of the problem.
We have separate version numbers for each libav*, which makes people think
that the libs are more or less independent from each other, while on the
same time we never supported linking libav* to another libav coming from
a different svn revision.

It is not that uncommon for a distro to support several major version of
the same lib at the same time. And distro generally don't support several
version of the same lib with the same major version.
So to make it clear, distro want to support simultaneously lavc51 and
lavc52, but they can't handle 2 version of lavu49 at the same time.
Right now, this is impossible.

I can imagine several solution to this.
One clean solution would be to never use any internal API of libav_x
from libav_y. Linking between the various libav* would strictly stick
to public API.
This would certainly imply exposing more things to public API of
libavutil. But that way, any change in lavu which would break
compatibility with old lavc, would also be a public API change, and
thus, would require major version bump.
I'm pretty sure this would solve the kind of problem reported here.

Aurel