[FFmpeg-devel] FOMS 2009 FFmpeg outbrief

[Aurelien Jacobs]

Michael Niedermayer wrote:

> On Mon, Jan 26, 2009 at 09:52:19PM +0100, Reinhard Tartler wrote:
> > M?ns Rullg?rd <mans at mansr.com> writes:
> > 
> > > Given that most of the complaints are invalid, e.g. the API hasn't
> > > changed nearly as often as they say, there really isn't much we can
> > > do.  If people want to make up false claims about FFmpeg, and then
> > > complain about them, they'll keep doing that no matter what we do.
> > 
> > I have been bitten by this this week. Several bugs have been reported
> > because of the recent ffmpeg update.
> > 
> > The root cause was the ff_gcd -> av_gcd rename in libavutil. On irc we
> > already could clear up this issue.  The rename was done to make the gcd
> > function part of the public API; it was private before. However the
> > *perception* of users is that ffmpeg has changed ABI/API. Why? Let me
> > explain it:
> > 
> > In debian lenny, ffmpeg is split in different binary packages, among
> > others libavcodec51 and libavutil49 using a snapshot from february 2008
> > [1]. In experimental, I've now updated the an snapshot from last week
> > end. Because of the version bump in libavcodec, I needed to rename the
> > binary package libavcodec51 -> libavcodec52, which is standard practice
> > in debian with SONAME bumps. The rename is done to assist transitioning
> > programs linking against libavcodec51: Packages not yet recompiled
> > against the newer ffmpeg are not instantly broken, because libavcodec51
> > left on the hard disk. It is only removed if nothing else depends on it.
> > 
> > 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]
> > 
> > In the end this means that libavutil49 must not be renamed until *all*
> > applications linking against any library of ffmpeg has been recompiled.
> > We now are aware of the issue and in future, we will express this
> > through package dependencies propoery, however the core issue stands:
> > Transitions to a newer snapshot of ffmpeg are made terribly painful this
> > way. Please note that the requirement to rebuild *all* reverse depends
> > of a library like ffmpeg is really a problem [2] for distributions like
> > debian or ubuntu.
> > 
> > I just tell you this story because I think it greatly contributes to the
> > *perception* that ffmpeg changes its API/ABI too often. From a
> > distribution POV, stories like these have the *same* *impact* as an
> > API/ABI change.
> 
> 1. why did you not tell this to us earlier
> 2. why did you not just add ff_gcd(){return av_gcd()} !?
> 
> in that sense, a patch doing 2. under #if ...VERSION < next major
> is welcome!

Trivial patch attached.

Aurel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ff_gcd.diff
Type: text/x-patch
Size: 577 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090127/6cbd6f09/attachment.bin>